LeanOrange | Author Archives

Enterprise Alignment

August 30, 2012 — Leave a comment

Alignment

In our consulting experience we have found many clients are excited to drink the Agile “kool-aid’ but for one reason or another fall short of a successful transition. There are many reasons failed transitions but one pattern that we have observed is a lack of “Enterprise Alignment.” So what do we mean by “Enterprise Alignment.”

An organization’s Enterprise Alignment is wrapped around three areas: technical architecture, business process, and culture. We have found that change initiatives fail when these three areas do not map to the overall goal of an Agile transformation.

For example, if an organization’s Agile transformation goal is to deliver business value fast, then all three Enterprise Alignment areas should align to that goal. Perhaps the technical delivery architecture take on continuous delivery characteristics, the business process would be focused on the flow of business priorities, and the culture would reflect a disciplined focus on shipping software.

Organizations fall short when they partially align themselves around these goals. They may have the technical architecture in place to enable fast delivery of software but are still operating on quarterly release schedules. Conversely the business process may be flowing the highest priority MMF’s or MVP’s to the development teams but the technical delivery approach is geared towards releasing batches of features through manual, late night deployments. Finally organizations may have the technical architecture and business process in place to flow features to production but lack the cultural discipline and collective ownership needed to consistently ship high quality software to production.

When considering an Agile transformation ask yourself, does my organization have the executive tolerance, courage, and leadership necessary to align the technical architecture, business process, and culture around the Agile transformation goal?

In Continuous Delivery, Culture, Delivering Software, Enterprise Agility, Technical Agility Enterprise Agility, Enterprise Alignment, Scaled Agile

Don’t sub-prime your project

July 20, 2012 — Leave a comment

Recently, a client ran into a roadblock…a major roadblock! For several months I had petitioned and warned leadership that investing the right talent to deliver results was putting the project at risk. However, no action was taken.

Essentially leadership took out a one year ARM hoping that they could deliver before the interest rate reset…i.e. team members to be repurposed towards other portfolio priorities. However, with the lack of the right talent the project made little progress. Month after month, the talent deficit accumulated into real project debt – software architecture, engineering disciplines, and team morale suffered tremendously.

Now management and the business are expecting the payment to come due(delivery). However they sub-primed the the project. With the expected due date coming up we’ll either need to refinance the project(add more time and/or resources) or foreclose.

So what? Irregardless of your process(Agile or not), when bootstrapping your projects, set your projects up for success. Put a solid down payment down to invest in realizing the project vision. Also, throughout the project lifecycle, actively engage the business and IT management…i.e. the decision makers. Transparency and active participation from stakeholders are key to Agile project success. Use this case study as an example where consistently disengaged decision makers caused project failure because they were unwilling to have the courage to make tough choices when the clear path to success was staring them in the face.

Reminds me of this sad Agile PM video: goo.gl/jYSWB

In Culture, Delivering Software

Slack

June 22, 2011 — Leave a comment

In case you haven’t heard, Washington DC has recently been crowned with the prestigious title of worst traffic city in the United States. Move over Los Angeles, there’s a new sheriff in town! As a resident and worker in one of Virginia’s main business hubs, known as Tysons Corner, I have seen my share of traffic jams. In late January of this year I had front row seats to one of the more memorable traffic disasters the Capital city has ever seen.

It was about 3pm when the first snow flake touched down. Almost immediately the office parking lots around Tysons Corner came to life with workers scurrying to beat the avalanche of traffic trying to rush home before the winter storm hit. Tysons Corner’s 120,000 workers rushed onto the area’s boulevard tributaries headed for the Dulles Toll Rd. and 495. I don’t think it could have been scripted any better. In a matter of 5 minutes, Tysons Corner’s major arteries reached 100% capacity and began overflowing and backing up into upstream side roads and parking lots.

After 3 hours of watching this debacle climax from the comfort of my office, we started seeing the futility of the situation outside. Stranded cars littered the roadway and shortly thereafter coworkers who had tried to beat the rush 3 hours earlier began returning to the office to tell their war stories. It was a truly a sight to be seen!

While this illustrates an extreme case of system overload, it draws similar parallels to the important correlation between capacity and throughput. Simply put, capacity describes how much stuff will fit into a system, while throughput describes to how much stuff will flow. This traffic catastrophe illustrates that the traffic system does not maximize the flow of vehicles when it is filled to 100% capacity. At 100% capacity, nothing flows. As it turns out, the optimal capacity to maximize traffic flow is about 65%.

Similarly, development teams do not maximize the flow of work when their workload reaches the team’s capacity. It is important to build slack into a team’s capacity. Slack allows team members to have time for emails, meetings, and impromptu office gabbing. Most importantly slack allows workers in the creative thinking world the buffer they need to architect a sound solution for complex problems.

Often times project managers want to fill their technical team’s capacity to the brim. Some PM’s want to put an equation together to figure out a team’s output or flow based on available hours. It’s really hard to estimate work in the creative thinking world. It’s so hard that it’s referred to as a black art.

Since precise estimates are nearly impossible to make, slack becomes even more important. It is best for developers to estimate based upon what we do know and make sure slack is built into our estimates to allow for a certain amount of discovery. After all, as a good friend of mine says, software development is more of an art than a science!

We’ll continue this conversation in our next blog post as we starting exploring limiting the work in progress.

In Lean Agile

From Scrum to Kanban – Part 5

June 15, 2010 — Leave a comment

http://www.bti360.com/uploads/Slide14.jpg

We’ve all observed the guy or gal at the daily standup that takes 5 minutes to report everything he or she is working. It’s almost a badge of honor to be soooo busy. However, a good Scrum Master would raise this up as an impediment to the team. Why might you ask? Lets answer that question with one of my favorite people skills. Answering a question with a question!

Have you ever seen the “card pile up?” Picture a scrum board with 2-3 days left in a sprint. Typically, the majority of tasks are still in “Execute” a few days before the end of sprint. Magically everything makes it to the “Done” column by the end of the sprint and the embedded testers give the developers <sarcasm> a high five </sarcasm> at the team’s retrospective!

Excessive Work In Progress is an impediment to a team because it puts sprint commitments at risk. A good Scrum Master will recognize this and try to bring visibility to this issue before it highjacks the sprint! In reality though, this impediment is rarely addressed. There has to be a better way to mitigate this risk!?!?!

Drum roll….the answer is WIP limits! WIP stands for Work in Progress.

WIP limits are placed on each work step in a team’s value stream that was mentioned in Part 3 of this blog series. Each WIP limit number represents the maximum number of stories or tasks that can be in “Specify”, “Execute”, “Test”, …etc at any one time. When the number of stories or tasks reach the WIP limit in a workflow step, no more new tasks are allowed to enter until something is moved. Therefore the team must surge resources around getting tasks done and not let them linger. Else a bottleneck in their workflow will surface and work will slow down or stop all together.

We like to say this forces teams to “focus on getting tasks 100% done, instead of a bunch of tasks 80% done!”

If your team needs to tame a task juggler, consider introducing WIP limits so you can “STOP STARTING and START FINISHING!”

In Kanban, Lean

From Scrum to Kanban – Part 4

April 24, 2010 — Leave a comment

http://www.bti360.com/uploads/tour-de-france.jpg

Now that we have the Value Stream defined the question becomes – What is the best way to process tasks through the value stream?I’ve found typical Scrum projects tend to “optimize the part” over “optimize the whole.” So – what is a part?

Think of the Tour de France. The Tour de France is broken into 20 stages. Each stage has stage winners. Than there is an entire tour winner.In this example, each stage is a “part.” When Lance Armstrong won his record 7 tours, did he focus on winning each stage or the entire tour?Understanding the difference between optimizing for a stage and optimizing for the tour changes the strategy for winning. Lets apply this to Kanban.Typical Scrum teams tend to optimize parts of the system. For example, developers will work really hard at coding the task and then 2 days before the end of a Sprint dump all their tasks on the Test Team.Here is what the Scrum board looks like:

http://www.bti360.com/uploads/ScrumBoard_OnDeck.jpg

http://www.bti360.com/uploads/ScrumBoard_Code.jpg

http://www.bti360.com/uploads/ScrumBoard_Test.jpg

I’ve seen this happen frequently on software projects. In this case the developers optimized coding ALL their tasks before the end of the sprint, but the test team doesn’t have enough time. So the team optimized coding but not the entire process.

In this case the team got 100% of the tasks 80% done – but until something is complete there is no progress. Kanban tries to fix this dilemma by getting something 100% done rather than many things 80% done.

How does Kanban accomplish this? Through the following techniques: