Join us for “Intro to the Agile Mindset”

Last Updated on Monday, 1 April 2013 09:22 Written by Jesse Fewell Monday, 1 April 2013 08:53

Friends,

I’m really excited to announce that I (Jesse Fewell) will be appearing TOMORROW for the latest PMI Agile Community’s Tweetchat. The topic is “Intro to the Agile Mindset”. We will all be on Twitter TOMORROW, April 2nd at 12pm EDT (Eastern US). The hashtag will be #pmiagile and I’ll be tweeting as @jessefewell with some commentary by @leadingagile.

Some of the proposed questions include:

• Q1: What is an Agile Mindset? #pmiagile
• Q2: How do I adopt an Agile Mindset? #pmiagile
• Q3: What barriers are there to an Agile Mindset within organizations? #pmiagile
• Q4: How does an Agile Mindset impact teams? #pmiagile
• Q5: Is Agile the same as Scrum? #pmiagile

Hope to see you then

Transforming Mountains

Last Updated on Monday, 26 November 2012 07:49 Written by Rick Austin Tuesday, 6 November 2012 09:42

In early October my wife and I vacationed at Cape San Blas, FL and I was struck by the beauty of the brilliant white sand on the beaches. They are impossibly white and it made me wonder how that sand came to be. I became fascinated by the time it took and the processes that made it so. I learned that when walking on that sand, I was really walking on ancient material from the Appalachian mountains. Eons ago the Appalachians were taller than the Himalayas but through the ages they have continuously been worn down and transformed. All of that material flowed towards and was deposited into what is now the Gulf of Mexico. The continuous motion of the waves deposited quartz that came from the Appalachians onto the beaches of Cape San Blas and other beaches on the Emerald Coast.

This extraordinary amount of time made me think about the time it takes for any type of change, including transforming an organization to work in an agile manner. Change is difficult, and much like the weathering away of the Appalachians, it takes patience, persistence, and focus on changing the right things at the right time. Successful agile transformations include elements of the following:

• A clear understanding of the existing organization: The landscape if you will.
  • What is driving the desire to move to agile?
  • What structures need to be changed?
  • How does the organization deliver value?
• Are there capabilities in place to deliver value: Are the right processes in place to turn mountains into sand?
  • Does the organization have appropriate skills in place?
  • Are practices in place that are required for agile teams to deliver value?
  • Is strategy connected to team’s ability to deliver value?
• Are the people aligned and wiling to change: Are forces working together and persistent?
  • Are people willing to work in ways that are different than what has made them successful in the past?
  • Is there a commitment across team members to collaborate and work together more frequently?
  • Do people understand the time needed to change and are willing to have the patience to see it through?

When there is organizational support for making structural changes, agile practices are embraced, and individuals are willing to change then conditions are suitable for a successful transformation. Just as suitable conditions were in place eons ago for the Appalachian mountains to be turned into brilliant white sand.

Even with conditions suitable for change, persistence and patience is required. Agile transformations in an enterprise are difficult because of the scale of change. Transforming enterprises, like transforming mountains, is difficult and takes time. Agile transformations don’t take eons, though they may feel like it, but they don’t’ take weeks either.

I often hear that we’ll just send some folks to a class or two and we’ll be agile. Just taking a couple of classes with no other transformation strategy is like banging on a mountain with a hammer, it may be a good way to start but much more is required. Your organization must have a real commitment to change and the patience to see it through if you intend to create your own white sand.

Here’s to improving your organization’s ability to deliver value, to your ability to create your own version of Cape San Blas’s brilliant white sand.

Beware of Common Sense

Last Updated on Monday, 19 November 2012 11:15 Written by Dean Stevens Thursday, 20 September 2012 08:00

When working with organizations in Agile transformations, I help them to do what makes sense. I encourage them to challenge me when they think I am suggesting something that does not make sense.

Do what makes Lean-Agile Sense
Here is the rub. When I explain what makes sense, I talk in terms of “principle based” sense. Agile Sense provides a set of values and principles to guide our decisions and actions to achieve an Agile mindset. Lean Sense explains some of the process science of flow embodied in Agile methods. It is surprisingly easy to loose sight of this at key moments. Education and training on the Agile Manifesto and Lean Thinking is critical early on.The rest of the coaching engagement is a pragmatic application of Agile and Lean sense in decision making. This is a great way to help them learn and for me to make sure they understand.

Beware of Common Sense (and Be Aware of Culture)
Organizations and individuals will face challenges in an Agile transformation. They will struggle with decision making to solve these challenges. This struggle is good. But if they are not intentionally doing what makes Lean-Agile sense, they will inspect and adapt away from Agile. Teams tend to revert to solutions based on common sense in the organization. Common sense is the knowledge and experience most people have. It is based on what has “worked” in the past. It is remarkable how fast a group can slide back to what they did before based on common sense.

A Bias for Less
Common sense tells us we need more of the things on the right of the Manifesto. More documentation and following the plan. These are comfortable and safe. Agile sense encourages a bias for less on the right. Encourage a bias for less of the items on the right instead of more.

For example, as teams struggle understanding what to build, some managers want to solve the problem with more documentation. Agile Sense encourages progress towards working software. Start with getting getting better at collaboration to demonstrate software sooner.

Common sense tells us big batches lead to efficiencies of scale. Lean sense explains big batches lead to expensive delayed feedback and wasted effort that out weigh these efficiencies. Without fast feedback, we do not learn as we discover the solution.

Be Vigilant

Stay engaged in retrospectives and decision making. Look for common sense solutions.

• A bias for more of the things on the right side of the Manifesto
• A bias for bigger batches
• A bias for delay in feedback

Change the conversation with Agile and Lean sense. Promote a bias for less, not more.

Team WIKISPEED at Agile 2012

Last Updated on Friday, 16 November 2012 01:24 Written by Derek Huether Tuesday, 28 August 2012 10:41

Regardless of where I coach or teach, there is always someone who approaches me and says something like, “Agile is great for software projects but what about projects that aren’t software related?”  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I’ll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize.

While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team’s SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to “better” their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we’re able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can’t afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can’t do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe’s session from TEDxRainier

That’s Not Agile!?

Last Updated on Monday, 3 December 2012 05:55 Written by Mike Cottmeyer Tuesday, 24 July 2012 05:00

Agile at the Enterprise Level is not about the two-week inspect and adapt cycle… it’s about small batches and flow.

You may have noticed that LeadingAgile is growing… and we are growing fast. Why? A large part of our approach to selling involves deeply understanding what our customers need and helping them craft solutions that meet them where they are. Some of the companies we work with are inventing new markets and creating emergent new products. Many of them though are desperately trying to figure out a way to deliver against defined commitments to existing customers. They desperately need some ability to do what they say they are going to do.

Businesses need to be predictable… they need to be able to regularly and reliably make and meet commitments. If you talk to these companies, many of them will tell you that they need to be predictable 12 to 18 months out. Personally… in most markets… I don’t think that is a reasonable expectation. For one… it is tough to really know how you are going to build the system that far out, and two… it is VERY unlikely that what a company thinks it needs 18 months from now is actually what it is going to need in 18 months. Needs are changing and markets are changing too fast.

For most companies we work with, the sweet spot is 3 to 6 months. If the product development organization can reasonably hit a 3 month commitment and have at least a high level idea what things will look like 6 months out… that is something we can work with. Even if a team is sprinting two weeks at a time… if they don’t know where they are headed 3 to 6 months into the future… chances are the organization is thrashing and the team will get frustrated. Even agile teams don’t like getting yanked around.

Getting Predictable

So… how do we get predictable 3 to 6 months out? First of all… let’s apply a principle that we know from team-level Scrum. For a team to make and meet a sprint commitment, the team must have some idea of what it will take to deliver the stories. If there is no acceptance criteria… if the stories are too big… if the team has no idea how to approach the work… we pull out one or more spikes to go figure that stuff out. A spike is simply a user story the product owner includes to help the team do the discovery and mitigate implementation risk and uncertainty.

The lesson here is that we can’t commit… even at the sprint level… to things that we don’t understand. There needs to be some prep work… in the case of a single user story… for a single team… for a single sprint… that is a spike. If we extend this metaphor up to the release level, that means that we shouldn’t commit to a release when we don’t have any idea how we are going to deliver that release. For a team to have a stable release plan… they need to know the Epic/Feature/User Story decomposition AND they need to have most of the release level spikes completed.

Release Spikes

What is a release level spike you ask? It is a slice of the product we build during the current release to mitigate risk and uncertainty in an upcoming release. We build the minimum set of user stories we can possibly build to understand the problem, prove the architecture, and define the backlog… so that when we exit release planning… we have not committed to work that isn’ well enough understood. It’s the same thinking we use at the sprint level, just applied one level up at the release level. Don’t commit to what you don’t understand.

So here is the rub… that means at any given time I need to have a well articulated backlog three months out… and a pretty good idea of what the backlog looks like three months after that. I usually refer to this as a three-month rolling wave plan. When I talk to folks about planning a well groomed backlog 3 to 6 months out… to many, that starts to feel like Big Up Front Planning… frankly it starts to feel like Waterfall. So… how do we plan forward… how do we mitigate risk… how to we get predictable without creating a big Waterfall Gantt chart?

3 Month Backlog?

The trick to establishing a rock solid agile release cadence and creating an organization that is able to make and meet commitments 3 to 6 months out… while staying agile… is all in how you write your requirements. It’s in how you define your projects. It’s how you schedule work in your organization. Frankly though… it’s not at the team level… it’s at the program and portfolio level.  Enterprise agility is about loose coupling between projects, and Epics, and Features… it’s about loose coupling at all levels of the organization. Remember that line in the Manifesto that says ‘we value responding to change over following a plan’?

That line doesn’t mean we don’t plan… it just means that we create plans that are resilient to change.

Small Batches and Flow

If at every level of the organization we focus on smaller batches… we focus on flow… we focus on limiting work in process… we focus on getting work done… we always maintain the ability to inspect and adapt. We always have the ability to change our mind as we learn new things about our product. We always have the ability to respond to change as we learn new things about our customers. Planning is how we mitigate risk… planning is how we define what we are going to do. We don’t throw up our hands and give up on planning… we look ahead and create plans that are resilient to change.

I’ll tell you… if you are having problems selling agile to your leadership team… it’s probably because the messaging you are using doesn’t resonate with them. Again… most of the folks that use our services care deeply about predictability. Do what you say you are going to do when you say you are going to do it. When things change, our plans will be resilient, and we’ll communicate and manage expectations accordingly… but leading with a message that says we can’t make and meet commitments is a non-starter. 3 to 6 months of well groomed back log helps that.

Enterprise Agile is more than Sprints

The point I’m really trying to get across here is that for most enterprises, agile isn’t about the two week inspect and adapt cycle… it’s more about smaller batches and flow at the program and portfolio level. It’s more about limiting work in process of major initiatives. It’s more about establishing a predictable and reliable delivery cadence that gives executives options for managing their business. Being agile isn’t about making it up as you go and not writing anything down… it’s about reliably and consistently putting products into market that your customers will use.