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)
Mapping a Value Stream to a Kanban Board
Lean Leaders: I’ve attached a link to a video from Alan Shalloway at NetObjectives. In this video, Alan Shalloway describes the process of mapping a value stream to a Kanban board and why both are important in improving business-driven software development… and he accomplishes all that in 15 minutes.
Kanban Distilled for Managers
Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.
The Effect of Bottlenecks
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.
Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.
If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.
Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.
But how do we know where the bottleneck is in any given process? And what happens when it moves?
Kanban reveals bottlenecks dynamically
Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.
Limiting work-in-progress reveals the bottlenecks so you can address them.
The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.
The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.
Worked Example
The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.
Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.
Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.
Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.
Next steps
How to get started with Kanban…
- Map your value stream (your development process).
Where do feature ideas come from? What are all the steps that the idea goes through until it’s sitting in the hands of the end-user? - Define the start and end points for the Kanban system.
These should preferably be where you have political control. Don’t worry too much about starting with a narrow focus, as people outside the span will soon ask to join in. - Agree:
- Initial WIP limits and policies for changing or temporarily breaking them
- Process for prioritising and selecting features
- Policies for different classes of service (e.g. “standard”, “expedite”, “fixed delivery date”). Are estimates needed? When choosing work, which will be selected first?
- Frequency of reviews
- Draw up a Kanban board.
All you need is a whiteboard and some Post-It™ notes. Don’t spend too much time making it look beautiful because it will almost certainly evolve. - Start using it.
- Empirically adjust.
from kanbandistilled.com/
Related articles
- Top Kanban Software (from AgileScout) (bobsleanlearning.wordpress.com)
- Kanban Leadership Workshop with David Anderson (kurthaeusler.wordpress.com)
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.
1 comment