Can Software Development Be Agile & Autonomous?
Those of us who work in the software development world are familiar with the term ‘agile’. But for us, this term is related to the Agile Manifesto. In Vijay Kuman’s TED talk, he speaks about ‘agile autonomous’ robots. He shows that decentralized control, local information, and anonymity work in this physical world. I wonder if we could use the same principles. He notes that the larger you make the quadrotor copter, the more inertia you have and the less agile it is. Hmmm… that sounds awfully familiar.
About this video: In his lab at Penn, Vijay Kumar and his team build flying quadrotors, small, agile robots that swarm, sense each other, and form ad hoc teams — for construction, surveying disasters and far more. At the University of Pennsylvania, Vijay Kumar studies the control and coordination of multi-robot formations.
Essence of Agile from Henrik Kniberg
I love Henrik’s agile slides. His work is quick and to the point, and visual enough to keep you interested and occasionally make you laugh.
Bob H
Related articles
- Learning Agile Software Development Using Tetris (slideshare.net)
Top Kanban Software (from AgileScout)
As I was looking for kanban software I came across this post from the pros as the Agile Scout. It seemed very “un-lean” to do anything but repost the info here!
reposted by Bob H
Top Agile Tools – Best Kanban Tools
http://agilescout.com/best-kanban-tools/
Kanban is growing like wildfire. Many organizations are finding value in this simple process via a “pull” system: The production of work is determined by the demand from the customer.You have a choice:
1. You can build a Kanban board.
2. You can use a tool and an actual board!
Here is a list of the best Kanban tools out there today.
Stay tuned for Tool Reviews from your very own Agile Scout!
Flow:
JAM Circle: *Open Source
Lino:
Scrumy: *AGILE SCOUT REVIEWED!
Simple Kanban: *Open Source
Got a cool tool to add to the list? Let us know. We review stuff.
Related articles
- Opining On Kanban (bobsleanlearning.wordpress.com)
- Karl Scotland on Kanban, Flow & Cadence (bobsleanlearning.wordpress.com)
- New Version of my Simple Kanban Board Application (codemonkeyism.com)
Opining On Kanban
I became a kanban advocate after implementing a kanban system for our instructional design team during my time at Delta. Before implementing the kanban, leaders assigned work to team members. As is the case in most organizations, we rewarded our top performers by giving them more work. With the kanban in place, the entire team was responsible for moving work through the process. Not surprisingly, our top performers still did more work, but since the work process was now transparent, all the instructional designers improved their performance.
As I work to discover how kanbans can work in the software development process, I found the follow blog posts helpful. I hope you enjoy them and I encourage you to visit both sites for more info on how lean works in software development.
Bob Hubbard April 2011
This post is from Dan Ackerson & Matthias Marschall’s “Agile Web Development & Operations website @: http://www.agileweboperations.com/scrum-vs-kanban
Scrum vs. Kanban
by Matthias Marschall on August 10, 2010 · 9 comments
When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which one is better suited for my own situation?Scrum – A Fundamental Shift
Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile methodologies: They have to start working in iterations, build cross-functional teams, appoint a product owner and a scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habbits and transform them into more effective ones.
Scrum Leverages Commitment As Change Agent
The initial introduction of Scrum is not an end in itself of course. Working with Scrum you want to change habits inside your team: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.
Kanban – Incremental Improvements
Kanban is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum
. In Kanban, you organize your work on a Kanban Board. There you have states which every work item passes through from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns starting from the right hand side based on the allocated capacity of each of the columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.
Kanban Leverages Work In Progress (WIP) Limits as Change Agent
For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.
Scrum vs. Kanban
Looking at both agile methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.
This post from Tobias Mayer at the”Agile Anarchy” blog.
Scrum and Kanban — different animals
On my last blog post Simple Scrum, Karl Scotland commented:
“Nice description. It also gives me a nice way of contrasting a Scrum and Kanban. Kanban says nothing about Roles, Artefacts or Ceremonies, but leaves the team to self-organise what works best. Instead, Kanban (as I describe it) suggests focussing on understanding the value stream, visualising it, limiting work in progress, establishing a cadence, and continuously improving [...]“
Karl’s comment helped me to see clearly that any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver, or an soufflé with a kangaroo. Which is better?
It was that phrase “value stream” that did it. It has always made me vaguely uncomfortable when I have heard it spoken in relation to software, and I wasn’t sure why. I have been thinking more about it, and I think I understand. There are two things.
This is a kanban (from kanbandistilled.com)
Firstly, I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas. Once you have mastered something, and go into building variations of it (e.g. web sites, or hand-crafted wedding dresses) then perhaps value-stream mapping comes into its own (there would need to be more similarities than differences). But before such time of repetition I suggest that to focus on a value stream is specious, and misleads people into believing that the creative process is mappable and repeatable. It is not.
Secondly, and more importantly, Scrum is a framework for organizational change It is people-centric. The focus of Kanban —as described here by Karl— is on business value. It is profit-focused. Focusing on profit will rarely transform an organization. Focusing on people and culture stands a better chance. The goal of Scrum —or at least, the goal of the Scrum Alliance, of which I am a member— is to transform the world of work. To do that, we must start with the individual, and we must focus on human values, not business values.
It has become clear to me that Scrum and Kanban are in place for different reasons. Sure, using Scrum you may increase your productivity and build better products (one would hope so!) and using Kanban may make people happier at work, but these are secondary concerns.
And lastly, a word for XP. If you are working with a software team, regardless of the process, and they are not using the principles of software craftsmanship suggested by XP, then please start there. Anything else will be a facade.
Agile Software Framework
Goal Driven Software Development Schema (Image via Wikipedia)
For the last half of 2010, I conducted an “Introduction to Lean IT” class for new hires into AT&T’s IT group. In every class I taught, someone asked about “Agile” and if Lean IT is the same thing as Agile. While Agile is not lean per se, there are many similarities. Here’s a pretty good overview of the framework from http://www.paradigmaseminar.org/
What is the Agile software framework?
Agile software development embodies methodologies and practices that facilitate an evolutionary approach to software development. Agile also advocates developing software in shot time periods, i.e. 4 to 6 week cycles. In addition a face to face communication model is also advocated by Agile. Although there is nothing new in these methods the Agile Manifesto seeks to bring together all of the best practices that create software:-
The Agile Manifesto is based on a set of principles that include:-
What is new about Agile?
In practice there is little new in the components that make up Agile, many of the principles are embodied in previously defined Joint Application Development (JAD) and Rapid Application Development (RAD) techniques. What Agile brings is a consolidation and discussion around those tools and techniques that advocate a leaner more iterative software development process that does not rely on a complete set of requirements being produced at the beginning of the cycle. In addition Agile, as a discussion forum, positions some of the newer software methods within this leaner\faster environment. These newer development methods include:-
The definitions of the above can be found on the web, but the point of the list (which is not complete) is to convey the fact that there are many evolving software development techniques that seek to address the essential difficulties of the software medium (that is software is not tangible and is defined as abstract models).Agile is best thought of as a mindset or forum under which certain methods and techniques are understood in relation to each other and in relation to solving the problems of software development.Agile is not a cure all or one size fits all and at some level it is easy to criticize. At the very least, however, Agile brings a fresh look at the software development process and is a positive forum for software process improvement discussions.
Where does Agile work well?
One area where Agile methods work well is User interface design. It is very difficult to sit down with a user and produce screen shots or Mock ups that depict the final software product in a way that the user can make a judgment as to the usefulness of the screens (interface). A working prototype, of just the user interface (i.e. no functionality behind it), has proved to be the best way of obtaining what the user really wants in terms of screen design. In short the user is saying I can’t tell you exactly what I want but when I see it I will know. This approach to software requirements works well when there is flexibility within the solution, or when there are a large number of alternative solutions to the requirement.
Where does Agile not work well?
Consider a financial application that has to satisfy some legal accounting requirements or a stock control system that needs to calculate re-order levels in a prescribed manner. Software applications that require certain functionality to be implemented may be able to use some Agile methods but they will require the specification to be produced in full before the design and coding can start. For these kinds of applications the functionality of the software needs to be fully documented and understood by the developers prior to any coding. An iterative approach to implementation will work but only if the whole system functionality is specified otherwise the structure of the system would be evolving as the requirements where fully understood. In short Agile works best when there is choice over the solution or when a non-functional requirement (i.e. usability) is difficult to document.
No guarantee (or claim) is made regarding the accuracy of this information.
Lean Software Development Podcasts
This is a great series of podcasts on Lean Software Development.
Chapter 1: A Developer’s Guide to Lean Software Development
This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.
This show focuses on Chapter 1, A Developers Guide ot Lean Software Development. We start to answer the question, if Lean’s goal is to focus on speed, quality, and low cost. How do you do it?
In the past, the approach has been to try to make every step and every person as efficient as possible. THat doesn’t work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality.
Lean says the better approach is to focus on removing delays.
Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter1
Chapter 2: The Business Case for Agility
This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.
This show focuses on Chapter 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition.
It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile:
- Deliver value quicker.
Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good! - Helping customers discover what it is they need.
Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang. - Better project management.
Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate. - Improving process faster.
It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months! - Letting your design emerge based on what you are learning.
While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so:
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Agile Software Development, Principles, Patterns, and Practices by Bob Martin
Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter2-business-case-for-agility Chapter 3: The Big Picture
This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.
This show focuses on Chapter 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas.
It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things?
Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas:
- Team agility
- Technical agility
- Management agility
- Business agility
Of course, where to start depends on your situation.
Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-big-picture Chapter 4: Lean Portfolio Management
This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.
This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.
What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up.
There is another benefit. We build these big project plans and even though we know they won’t work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards – so bedeviling – become a thing of the past.
Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter4-lean-portfolio-management Introducing Kanban for Software
Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach. Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about.
Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January.
Recommendations
Links above are from the Net Objectives website at: http://www.netobjectives.com/
The Three M’s – The Lean Triad
Posted by Roman Pichler on Feb 27, 2008 @ http://www.infoq.com/
The discussion of applying lean principles to software development has largely focused on identifying and eliminating waste (in Japanese: muda). Lean Thinking equally aims to remove overburden (Japanese: muri) and unnecessary variation (Japanese: mura). Muda, muri and mura are called “the three M’s.” Together they form a dissonant triad. All three M’s must be eliminated to create a sustainable lean process. This article discusses the relationship between the three M’s and argues that the elimination of overburden should be the first step for software development organizations in order to create a lean process.
(see the complete article: http://www.infoq.com/articles/lean-muda-muri-mura)bh
One Day in Kanban Land
some kanban humor from Henrik Kniberg
http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html
1 comment