Presenting on Agile PMO at Orlando Scrum Gathering

I'll be speaking at the upcoming Scrum Gathering in Orlando. The title of the talk is the Agile PMO: Scaling Scrum through Adaptive Governance, and the talk is scheduled for Tuesday. March 17th from 3:00-4:30. 

Hope you can make it if you're at the Scrum Gathering!

 

Arlen to Co-Present at LOMA Emerging Technology Conference

Arlen Bankston joins Bob Bell, CIO of the Armed Forces Benefit Association to co-present at the LOMA Emerging Technology conference in San Diego, CA.  They will be speaking about Large Scale Agile Software Implementation with a New Team.  From the conference website: 

“Hear how The Armed Forces Benefit Association utilized Agile software methods in concert with Lean process improvement principles to implement a new, mission-critical Policy Administration System designed to simplify infrastructure, automate manual processes and improve customer service. This case study discusses the challenges and successes faced when introducing highly collaborative Agile methods to a team of industry veterans as well as a discussion of improvements in time to market, quality, risk management and stakeholder involvement versus similar projects using waterfall methodologies.”

Visual Management – A Readable and Useful Taskboard

Visualization Techniques and Information Radiators

Using information visualization techniques to manage work is known as Visual Management. An Information Radiator (term created by Alistair Cockburn) is a publicly displayed artifact that conveys project information.

The Task Board is Key

In Scrum and other agile approaches the task board is the key Information Radiator and it is an example of using visual management techniques to enhance team communication and effectiveness.

Blog Post to Check

The blog post from Xavier Quesada Allue explains how a carefully designed task board, created with readability and usability in mind, can be used to drive planning and communication, to such an extent that even those that are not on the team can gain valuable insight into a project just by reviewing it.

I found this piece quite useful, and if you read it, it may help you answer the question, is my taskboard helping or hurting?

Scrumban – Moving To a Batch Size of 1

Agile and Scrum have come a long way towards improving time-to-market but is it possible that we can make our typical agile techniques even more lean?

There is a common training game in the agile community called the “penny game”. In the penny game, you have 4 players lined up and their jobs are to flip pennies and hand them off to the next person in line. In the first round, the first player must flip 20 pennies all to heads before passing the entire batch to the next player who then flips them all to tails and so on. You can measure how long it takes to deliver the first penny and last penny all the way to the end of the line.

If you have ever played the penny game, you have seen how it takes much less time to deliver the pennies to market, as transfer batch size decreases. In other words, working in batches of 20 pennies will be significantly slower than working in batches of 10 pennies, which in turn is slower than flipping in batches of 5, and so on. As we move closer and closer to continuous flow, we get faster and faster in our delivery.

In the software development world, we have traditionally been operating in large transfer batch sizes where we analyze all of the requirements for an entire system before handing the entire batch over to development where we then write all of the code and then hand that huge batch of code over to testing, etc. As the penny game teaches us, this is the slowest method of delivery.

In the agile community, we focus on decreasing that batch size down to just a few weeks worth of work at a time and by reducing the batch size, we greatly improve time to market. It is common in Scrum to focus on batch sizes of 2 – 4 weeks worth of work that is organized into time-boxed iterations. At the end of each iteration we stop the line and re-plan for the next batch delivery. For many organizations, this results in huge improvements in time-to-market. But what next? Once teams have reached the benefits of scrum, where do they go next?


In Scrum, Batch Sizes Can Be Further Reduced for Faster Delivery
Organizations that have successfully used short iterations may be ready to take the next step. As we move closer to a batch size of 1 and closer to a state of continuous flow, our time-to-market will improve yet again. This is where “scrum-ban” comes in. The word scrum-ban comes from the Japanese word “kanban” combined with Scrum. In Scrum-ban, we move even closer to the ideal:

• We do not need to stop the production line every 2-4 weeks for rigorous re-planning of the upcoming iteration. As work requests come in, we prioritize them, give them very rough estimates in real-time, and then put them into the queue at their appropriate point in the backlog. When the team finishes a piece of work, they pull the next highest priority item from the backlog and focus on delivering it.
• There is no need for iterations with batch sizes of 2-4 weeks worth of work. In scrum-ban, we aim towards continuous flow and continuous delivery.
• In Scrum, we put significant emphasis on estimation because we need to commit to a batch of work that will fit into the 2-4 week iteration boundary. In scrum-ban, we have no such artificial boundaries so we can reduce the effort required to create estimates even further.

This article just touches on the ScrumBan concept, and putting the concept to work is non-trivial, but even with this short introduction I think that you can see that we can make another leap in productivity and speed to market by moving towards even smaller batch sizes, reducing the need for time spent on estimation, and eliminating the need to stop the production line for iteration planning.