Recap of LSSC12 Conference

I just returned from the Lean Software and Systems conference in Boston. There was a definite common thread around learning cultures and a focus on treating our industry as a set of scientific experiments. The heavy influence from the Lean Startup movement was prevalent. Here are some of my takeaways for those that were not able to attend.

Steven Spear

• Greatness is achieved by increasing the pace of learning

David Anderson

• Kanban Principles
• Start with what you do now
• Agree to pursue incremental evolutionary change
• Initially respect current roles responsibilities and job titles
• Encourage acts of leadership at all levels from individual contributor to senior management
• Implement feedback mechanisms added
• Steps for converting to Kanban

• Understand sources of dissatisfaction
• From viewpoint of internal and external
• Source of variability that cause dissatisfaction
• Demand and capability analysis
• By work item type and class of service
• Model workflow
• Understand the knowledge discovery process by type
• Kanban system design
• Visualization
• Roll out plan

Steven Denning

• Dude’s Law - David Hussman
• Value - Why/How
• Focus on the Outcome
• The only valid purpose of a firm is to create a customer
• Not create shareholder value
• Switch your focus from Outputs to Outcomes
• Customer Delight = Providing a continuous stream of value to customers and delivering it sooner
• The goal is to delight the customer. Everything else is a means to getting there

• Less is more. Aim for the simplest thing.

• Costs will come down because you will only focus on things that delight your customer

• Commands kill conversation

• Money kills inspiration

Dominica DeGrandis - Kanban for IT Operations

• Need to get visibility to dependencies because they carry risk

• Design your SLA’s into your board. Create timeline like tick marks across your in progress column and move items each day.
• Problems with board where there are names for swimlanes
1. Standups are focused on individuals
2. Perception of poor performance
3. Limits Collaboration
4. Focus on utilization
5. Pigeon hole folks
• Bring visibility to skill levels of different skills required on team
• Make interrupts visible
• Institute the Goalie.

• Handles small interrupts
• Rotates Weekly
• Expands Knowledge base
• Gain flexibility in team
• Make a policy on when the team should create a ticket for something (i.e. takes more than 4 hours)

Jeff Patton

• Focus on Value
• Don’t focus on maximizing the output, focus on maximizing the impact of the outcomes
• Think beyond the edges of the Kanban board

Arne Roock and Markus Andrezak

• “Projects” are like waterfall containers that have planning, time constraints, focus, budget and purpose
• Replace projects with epics that align to strategic goal/ outcomes. Let the team work to achieve those outcomes

Don Reinertsen

• Compared Software to Firefighting, “You don’t just say this is a complex adaptive problem so we can’t create a plan”

Jim Benson

• Change happens in evolutionary leaps
• Kaizen is a status quo monster

Misc

• Can run simulations through board http://www.focusedobjective.com/
• “Standard” is just the status quo written down

Some of the presentations:

• http://www.slideshare.net/cperrone/a3-kaizen-heres-how
• http://prezi.com/lobpkyhtrhf6/continuous-improvement-is-broken-lssc12/

Infrastructure Agility

Whether your team is agile, lean, or anything else you have likely run into frustrations with your infrastructure. See if any of the following strike a chord with you:

• You aren’t sure how your servers are configured
• Your servers, workstations, etc. aren’t configured the same way
• Nobody is sure who changed a configuration file, or why, and what was the last good version of the file?
• Who installed that rogue server process? Why was our standard version of a dependency upgraded that is now breaking our applications?
• Why are our development servers configured differently than our QA servers? What will it take to make them the same?
• How long will it take to upgrade or install application x on our cluster of servers?
• Your developers/QA/UAT Testers are blocked 3 days waiting on ops to install/upgrade a server with something new needed for a story
• It takes 3 days for new developers to get set up with all the standard dependencies (or the machine image used has old/missing versions and needs a lot of upgrading)

No matter what your particular frustration, your infrastructure and systems take time and effort. We see it all the time, but it is especially frustrating when teams following lean/agile principles who have put effort into eliminating waste and providing quick feedback find themselves against another wall they must continually climb and are regularly slowed.

Getting Control of Infrastructure

We don’t advocate solving a problem you don’t have, so if frustrations like those mentioned above are not among the bigger problems affecting you, just file this away for later.. But for many of you the above probably resonates.

So, where do you start?

Outsource It!

First, why not just fix the glitch? Why spend time trying to address a problem you can get rid of? Look at your application, infrastructure, whatever that is causing you pain. Is it standardized enough that you can just offload the problem?

We don’t want to just move the problem to a team doing the same thing in another location. What I’m referring to is taking advantage of platforms that have taken common deployment or infrastructure scenarios and packaged the operations around them as a service. You do this when you choose to host a server on a cloud service like [Amazon] or [RackSpace]. This kind of cloud computing model which abstracts and automates the details of physical hosting of storage and computing resources is often referred to as Infrastructure as as Service, or IaaS.

You can take this to another level by using a service like Heroku or AppFog that removes the need to manage servers and instead deploy to more highly managed environments that accomodate certain solution stacks. If your application fits their managed platform or isn’t too customized you can avoid having to deploy both servers and much of your solution stack, focusing on your core application code and configuration. This level of cloud computing services is often referred to as Platform as a Service or PaaS.

Offloading what you can offers you reduced complexity of operations for some or all of your environments. But for many teams we have found constraints that don’t allow taking advantage of these types of services.

Control It!

Whether you have resources in the public cloud, private clouds, or on good old bare metal hardware, you have work to do to manage provisioning, configuration, deployment, and tracking of assets and infrastructure.

Agility in infrastructure is achieved through:

• Providing good visiblity on the infrastructure you have
• Eliminating bottlenecks to adding / changing your environments
• Minimizing complexity
• Being able to adapt quickly to changing business needs
• Having a high level of communication and visibility across all those involved in delivering software to end users

Many operations teams already track assets in various places. Some keep standard configuration files and checklists they use for consistency. Others have scripted common tasks in their daily operations work. But not all do these sorts of things. And even if they do, manual work ends up being the biggest bottleneck of all. The path to agility requires finding straightforward, consistent ways to communicate, control, and automate your infrastructure management.

Infrastructure as Code

While not necessarily new, there has been some disruptive change in recent years led by the growing popularity of tools like Chef and Puppet. Similar tools, such as CFEngine have been around much longer in different incarnations both inspiring the newer generation of tools and greatly evolving in their own ways. The combination of these types of tools with the rapidly expanding selection of virtualization and cloud tools.

The philosophy is simple, with the support of the right tools a team can create configuration files and scripts (code) that describe what their infrastrcuture should look like and how to go about creating it. This code can be executed to provision systems, configure and install dependencies, deploy applications, take inventory of what is deployed, and keep things consistent.

As Jesse Robins once described, the goal is to:

Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.

Such an approach to managing insfrastructure isn’t limited to servers either. Some groups use it to help keep developer, tester, or other types of desktop machines up to date with the latest tools/configuration a team needs. When you have only a few machines to manage such an approach is neat. When you have hundreds or thousands it becomes essential.

Hopefully this has piqued your interest or brought awareness to how we include infrastructure in our assessment of agility and waste. As always, don’t solve a problem you don’t have. But if infrastructure issues are affecting your team and you have identified the bottlenecks stay aware of your options.

We will follow up with additional posts in this series on Infrastructure Agility with looks at DevOps and a closer look at tools like Chef and Puppet.

A Tried and True Method for Retrospectives

I feel the Retrospective is the most important ceremony, especially for new teams. I am concerned when ScrumMasters boast they can get their Retrospective done in 30 minutes or less. I must ask, “Did your team learn anything? Are they improving? Are they pushing themselves through the Tuckman Model and getting close to becoming a High Performing Team?” 


In my experience, new teams need 1.5 - 2 hours for a healthy retrospective. They need time to reflect on the Sprint and fully explore opportunities for improvement. The retrospective is a key ingredient in engaging teams to take ownership of their own process and figuring out how to improve. In this post, I will walk through my standard approach to a Retrospective.

Goal

It is easy for the team to identify a laundry list of problems, but the team can’t address more than a couple at a time. The goal is to devise 1-3 actionable items the team can change during the next Sprint timeframe. If the team can make a 2% average improvement every two weeks, they would accomplish over 50% improvement on the year. In order to encourage more significant improvements, we also need to help the team have the courage to try some more radical changes.

Set the Tone

When I kick off a retrospective, I want to make sure it is a safe room for the Team. This includes the team members (Pigs), ScrumMaster and Product Owner, but does not include chickens, stakeholders or managers. We also want to defuse negativity. I usually kick things off with a statement like the following:

“We are looking for changes that we the team can change. This is not a blamestorming session (I usually point with my fingers outside the room), this is a chance for us to reflect on what we (pointing at myself) can do better as a team.”

I might also put the Norm Kerth quote up if I think there might be some attacking of individuals:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When setting the tone, I also like to share our current metrics. Things like:

• The Sprint Burndown
• Sprint Results (Points planned vs. completed)
• Release Burnup to show progress on overall goal

This helps the team review some of the facts around their performance and effectiveness.

Data Collection

The next thing to do is gather some data and insights on the Sprint. The standard way to do this is Start, Stop, Continue. I create three sections on the wall or whiteboard with those titles and have the team come up with as many items as they can in 5-10 minutes. We are looking for:

• Things that worked well and the team should Continue
• Things that did not work well and the team should Stop
• Things that the team did not do and should Start

This exercise should be silent with folks writing individually. This tends to prevent a couple voices from dominating the discussion and get the introverts to participate a little bit more. We want to give the team members time to reflect to themselves on opportunities for improvement and reinforcement.

They should all be writing at the same time with provided Sharpies and Post-it notes. They should write one item per Post-it, which can be put on the wall anytime. Sometimes, the early ones will help others generate ideas, but this is all done silently. The Sharpies are important so that everyone in the room can see what is written on the Post-it. Once I see that no new ideas are being generated, I move on to the next step.

Read for Clarity

I introduce this step by saying:

“Now we want to read through the items to get an understanding of what everyone has written. On this first pass, we just want clarity so we don’t want to get into discussion or debate. If you are unclear of the meaning of what someone wrote, just ask and that person can provide a brief description of their intent and then we will move on to the next item. Now who can come up and read one of the columns?”

I have volunteers from the team read the items to foster ownership by the team. As the facilitator, make sure the volunteer is reading slowly enough so participants have enough time to digest. If after a couple have been read and no one has asked to clarify, I typically will ask for one to be clarified so people recognize it is ok to interrupt. Once they have finished one column, I thank them and ask for another volunteer until all three columns are read.

Group and Theme

In the next phase, we will organize what we have to determine where to focus our discussion because there is rarely time to discuss everything.



I ask everyone, or for large teams everyone who did not volunteer to read a column, to stand up and go to the board. At the board, we want everyone to do a silent sort (for speed). They should put like items near each other (without covering up the others). At this stage, it is ok for items to move across columns. Once they have a grouping, they should label the themes. It is ok to have a couple oddballs that don’t fit into the groups.

Prioritize

If you have 3 or less core themes, focus on those and start with the one with the most items. If you have more, then you need to prioritize. I like to use dot voting. I give each person 3 dots (Stickers) and ask them to vote on the topics they think are the most important to tackle. They can put all three on one item or spread them across multiple. They are voting for a theme not individual items. (Hint: ask them to place them on the Post-it as it is much more difficult to peel them off of the whiteboard or wall.)

Discuss

Based on the voting pick the top 3 items and set a timebox of about 15 minutes per item. Ask an open ended question on the topic and then let the team own the discussion. (i.e. “So what do you guys see as the underlying problem here?”) As the facilitator, try and refrain from leading this discussion. We want the team to drive it and it is ok for the discussion to wander a bit. After 5-10 minutes, try and bring it to a close with something actionable the team can change. Prompt them into solutioning by asking something like, “So what can we as a team do about this?”

Take Action

Make sure the team comes up with actionable changes, i.e. SMART goals. Ensure the team discusses how they are going to make it happen. Create immediate tasks in the Sprint Planning session that should follow. Make the goals visible and part of the plan, i.e. put them on the task board.


Other Variations

• Don’t let it get stale. Try different things. I recommend buying Esther Derby’s book (listed below) to help generate new ideas to keep your team engaged.
• Other favorites: Speed Boat (Innovation Games), Triple Nickles (Esther), Mad/ Sad/ Glad (Esther)
• Sometimes just have a conversation as a team
• Occasionally just focus on a team building exercise
• The problems aren’t always clear and you will need to do some root cause analysis. Some great tools for that are a Fishbone and the Five Why’s.
• It is ok for the ScrumMaster to set a focus topic of the retro. i.e. Let’s focus on self-organization or being releasable at the end of the sprint
• For Release Retrospectives I like to do the Timeline (Esther) exercise or Remember the Future (Innovation Games)

References

1. Agile Retrospectives: Making Good Teams Great, Esther Derby & Diana Larsen
2. http://innovationgames.com/

Announcing Agile-Lean & Kanban Foundations Class Aug. 1st

Agile-Lean & Kanban Foundations introduces Lean and explores its relationship to Agile Software Development. The class will look at Kanban as a Lean approach to incremental, evolutionary process and systems change for organizations and how it can be used to develop software according to the values and principles of Agile. 

Conducted by Agile Velocity. 

Location NW Austin TBD 

The first 5 registrants will receive a $100 discount. 

http://agilevelocity_kanban.eventbrite.com/ 

Class Highlights:

• Introduction - Agile foundations 
• Lean concepts 
• Kanban concepts 
• Agile teams and roles 
• Planning 
• Requirements 
• Estimation 
• Best practices 
• Continuous integration 
• Interactive exercises throughout the workshop 
• Onsite lunch will be provided 
• Q&A 

Who Should Attend?

Engineering Managers and Team Leads, Developers, QA Engineers, Product Managers, Scrum Masters, Product Owners, Business Analysts, Program Managers, Information Architects, Executive Management with oversight responsibility, and anyone interested in incorporating Lean or Kanban practices into an Agile development process. 

Kanban vs. Scrum – How to Choose?

Kanban vs. Scrum – How to Choose?

My clients frequently ask me when to use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions I ask:

Do your priorities change often? Do you have trouble locking scope for 1-2 weeks at a time? Do you have more than 25% scope churn during a 2 week period? 

If you answered yes to these questions, score 1 for Kanban. By dropping the fixed timebox, it will allow your team to adapt more easily to the quickly changing priorities of your business.

Do your teams struggle to break features into incremental pieces of value to be delivered in less than a week?

If you answered yes, score 1 for Scrum. Both frameworks work best when you break your work down into small incremental pieces. I find the Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).

Do your teams struggle with estimation or question its value / overhead?  Can they break work down to reasonably small, similarly sized chunks?

If yes to these, score 1 for Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items.

Do your teams have a strong culture of continuous improvement and self-organization?

If so, score 1 for Kanban. The lightweight framework that Kanban provides works very well in a culture of continuous improvement. They will know the right times to hold a retrospective. For teams new to this practice, the regular cadence of a retrospective ceremony will help teams establish this practice.

Are your teams highly disciplined with technical practices and craftsmanship, such as TDD, Continuous Integration/ Delivery, Shared Ownership, etc.?

If you answered yes, score 1 for Kanban. Note that both frameworks excel in an environment of strong technical practices. However, a Kanban team may be able to reach a higher optimization level by having a constant flow of work.

Is your team's top priority to optimize responsiveness to customer needs?

If so, score 1 for Kanban. Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.

Is your team's top priority to focus on predictability and productivity for larger projects?

If so, score 1 for Scrum. Again, you can achieve predictability and high level of productivity under both frameworks. For new teams, Scrum provides more guidance and resources of how to handle release planning and progress tracking.

What is the appetite for your team for process change?

If low, then score 1 for Kanban. Kanban has a lower level of Ceremony and may be easier to incrementally introduce into your organization.

Does your organization/ culture demand a higher degree of ceremony and artifact?

If so, score 1 for Scrum. Not that Scrum has a high level of ceremony in comparison to methodologies such as RUP, PMBOK, and PRINCE2, but it can integrate well into a culture requiring more documentation. From a Lean perspective we would question the need for this potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.

Summary

Both Kanban and Scrum require strong discipline to do well. Kanban doesn't have as many rules which is good, but it also can be taken advantage of by an undisciplined team. Both can be abused: Scrum teams could constantly carryover unfinished work or Kanban teams could ignore WIP limits. Scrum's Sprint time box or Kanban’s WIP Limit should force teams to figure out how to break things down into smaller pieces.

I see teams most successful with Kanban fit into two areas: 

1. Support the business teams - These teams are focused on serving the business to keep the software running. Their priorities can change on a daily basis with frequent delivery of software. These teams need to optimize to be ultra-responsive. Kanban can enable these teams to optimize flow.

2. Mature, disciplined, self-organizing teams. They are engaged in the process, understand how to break down work and are constantly swarming to get things done.

Where do you see one fit best over the other?

David Hawks is an Agile Coach and Trainer based in Austin, TX who helps organizations transition to Agile by implementing either Scrum or Kanban.

Agile Velocity provides Agile Coaching/ Training (Scrum, Kanban, Lean), Agile Technical Practices Implementation and Team Augmentation Services.

Heard at the Houston ALN Conference

"The role of an agile leader is to create the conditions for agility by taking action to change culture, structure, and goals"

"Fail at the small in order to succeed at the big"

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.” Darwin

"Leadership teams need to be focused on global optimization, not optimization of their own teams"

"Organizations need clarity on overall purpose, so that empowered self organizations can be powerfully successful"

"Shorten the decision paths, empowerment, alignment on purpose, shorten feedback loops"

"Never start without the purpose"

"Have metrics not to manage by, but to leverage to start conversations" Mike Young

You Can't Do Agile If You Haven't Seen Agile

• Mark J. Balbes, Ph.D.
• 11/10/2011

"You can't implement an agile program if you haven't seen it in a successful environment. It's just too different from traditional methods. If you try to do it without the help of someone who's lived it before, you are very likely to fail because you won't know the techniques to solve the unique types of problems that come up. Agile is not a panacea that will solve every problem. Sometimes it creates problems that you wouldn't have in a more traditional environment."


http://adtmag.com/articles/2011/11/10/agile-transitioning-must-see-agile.aspx