iterative and incremental

Agile software development is typically iterative and incremental. The software requirements are sliced and planned into iterations.  The software is built incrementally, with newly developed slices being added to (or deployed with) the working slices. The figure below is depicts the nature of Agile software development.

the work cycle

Agile software development progresses in small development cycles that typically last from one to four weeks. As you can see in the figure above, there are several activities that happen within a development cycle. These activities differ depending on your flavor of Agile, and the maturity of Agile within your organization. 

Agile incrementally delivers increasing value over time, whereas the traditional software development process delivers no value until the end. The figure below depicts typical Agile incremental delivery by means of consecutive iterations.

delivering  incrementally

The figure above illustrates three consecutive iterations. The overall requirements are represented by a backlog of work, which is a collection of smaller pieces of requirements. Then from the overall backlog, the work is selected for an iteration. Scrum calls these product backlog and iteration backlog, respectively. Subsequently, as the work progresses, it is continually integrated with the previously completed work. Finally, the work completed within the iteration is either released, or waits for complementary work from future iterations.

The graph of functionality versus time (below) provides an effective visual representation for Agile and traditional development delivery styles. In this graph, the X axis represents the elapsed time, and the Y axis represents the delivered functionality.  

graph functionality versus time

The graph above represents the project at the beginning, or time zero. In this case no functionality has been completed yet. And this is the same situation for Agile or traditional software development. The figures that follow show what is delivered in Agile versus traditional software development teams.
 
Traditional sequence:
 

Agile sequence:
 

 This sequence shows how Agile delivers small slices of functionality over time, while the more traditional software development style only delivers at the end. 

Agile Software Development

Software development is empirical, hence you need processes and practices that allow the team to adapt to circumstances, and effectively work with Software development and its empirical nature. To this end, Agile shifts the focus from heavy planning and repeatability to focus on demonstrating results and adapting to changes. 

That’s not to say we should stop planning. We still need to plan—and understand variations from the plans—but plans are not to be set in stone; they are meant to be flexible. 

Agile emphasizes empirical process control. This is the idea behind inspect and adapt. Many Agile practices are all about this intent, such as: Scrum’s sprint retrospectives, Lean’s kaizen, and XP’s weekly iterations and short releases. These practices are about looking back and adapting: constantly recalibrating, improving, and doing course control.

whiskey and flow presentation

John little, whiskey and flow from paulocaroli

Optimizing the flow workshop at Porto Alegre (Dec 2012 edition)

The Optimizing the flow workshop at Porto Alegre (Dec 2012 edition) was awesome!

Once again, I did learn a lot while giving the workshop, and having great conversations (group and individually) about the participants real projects experience.

The whiskey and flow presentation was the participant’s favorite. Note to self; keep using it.

Something I said which people really liked:

My wife celebrates every time I empty a whiskey bottle.

So, what can I do to my bar that would make her happier?

…

Reduce the bar size (less bottles means lower lead time; she will receive empty bottles faster)

Below are some photos from this workshop instance.

Thanks for the feedback!

6 Dec:
 Nelice Heck ‏@NeliceH
@paulocaroli very good workshop. Wish we would have more time to go over and also debate more about the concerns on our project!

Henrique Imbertti favorited your Tweet
5 Dec:
Control Flow Diagram and Control Chart; same team and requirements, WIP limit was the only change pic.twitter.com/DEBBr35d

5 Dec  Paulo Nonaka ‏@paulononaka
@paulocaroli hey Paulo awesome workshop! I would be really happy in apply any of those teachings in my project!

5 Dec  Jefferson Girão ‏@jeffersongirao
Awesome workshop "Optimizing the flow on agile projects" by @paulocaroli today! http://www.optimizingtheflow.blogspot.com.br/ 

5 Dec:
Workshop on optimizing the flow. Live from Porto Alegre pic.twitter.com/a0aszQ0D

5 Dec:
Control Flow Diagram and Control Chart; same team and requirements, WIP limit was the only change pic.twitter.com/DEBBr35d

5 Dec  Max Lincoln ‏@devopsy
Great workshop on http://www.optimizingtheflow.com  today by @paulocaroli. I just wish we more time to talk about distributed #agile teams.

5 Dec  Mauricio Sanches ‏@bauricio
Impressed on how making implicit concepts explicit on the Kaban board helps workflow after @paulocaroli workshop (https://sites.google.com/site/optimizingtheflow/ …).

5 Dec  paulocaroli ‏@paulocaroli
Thank you! "Excellent workshop on optimizing the flow on agile projects today with @paulocaroli. The aha! moments were priceless! "

5 Dec  Alexandre Klaser ‏@alklaser
Excellent workshop on optimizing the flow on agile projects today with @paulocaroli. The aha! moments were priceless!

5 Dec  Anshul Mengi ‏@anshulmengi
Awesome workshop. @paulocaroli

Richard Rosário favorited your Tweet
5 Dec:
Building a CFD and a control chart manually pic.twitter.com/J2XfBPp3

online tools for managing workflow

Here is a quick comparison done by my colleague PauloNonaka on a few online tools for managing workflow.

Trello

Some cool stuff on Trello:

• priorities vertically – I can prioritize debt tech over stories, stories over bugs and etc
• clearly who is working on what (avatars) - them clearly can see our capacity limit
• plugin for WIP limits
• it shows tasks completion while developing a story
• it shows when there is no pairing on a story (or when we have a threesome or even more :) )

Also figured out that I can export and treat Trello's data:

• Project progress tracking with Google Docs and Trello
• Extending Trello for Sprint planning

Negatives points:

• No more than 7 labels (but I don't see it as problem if we in separate teams in different walls provided that all things related to the same team keep together)
• No historic when moving vertically

Rally Kaban also seems pretty nice. Although I didn't figured out how to set up pairs in the cards and how to add tech debt cards. 

I insist that tech debt cards should be together among stories. In this way we can easily (and visibly) define priorities based on our real WIP limit - that is not visible when we have cards spread over many walls and emails.

Kanbanery seems pretty cool, although it's not free.

It has some cool WIP oriented reports like lead & cycle time (by task type), cumulative flow chart, and task distribution.  

I also want to check out Agilezen (not free) and Kanbanize (free).

Kanbanize seems very flexible and it has reports as Cumulative Flow, Cycle Time, Task Distribution and Block Resolution Time. I tried it a little bit and it has the same problem as Rally Kaban - just has a field for owner.