Archive for the ‘Scrum’ Category

Lean-Agile Mindset – The Secret Sauce

Lesson Learned: Fund Agile Value Streams instead of Projects, for High Performance

For 12 years I’ve led organizations structured with Scrum/Kanban product delivery teams, shared services teams, and cross-functional roles embedded in these teams. Guiding and encouraging these teams to be effective in their iterations and their evolution into continuous delivery pipelines results in vast improvements over waterfall or some variant of “scrumerfall” SDLC patterns. However effective these teams become in the SCRUM/KANBAN mechanics, the company can only be high performance when work is funded through the value stream and not by projects.

Over the last year I’ve been working as a SAFe(R) (Scaled Agile Framework) solutions architect for cPrime.  Participating in the SAFe Agilist certification training I experienced a transformation in my thinking that emphasizes managing lean budgets to fund work. I’ve had the opportunity to work in several fortune 500 companies both domestically and abroad, and reflected on my last several years in contributing to scaling our agile organization at Constant Contact as a Director of Quality Engineering. The most striking realization that was revealed to me is that no matter how hard you try to get to a high performing Agile company (DevOps CI/CD pipelines), if the corporate financial structure does not change to Lean-Agile approaches then the company will never get there.

Lean-Agile leaders all support the notion of Lean-Agile Mindset that includes funding work through value streams (or equivalent constructs) where the work is brought to the teams, rather than the traditional project management approach of funding projects and bringing the teams to the project.

  • Funding Value Streams requires the company to recognize the teams build a coordinated pipeline of capability (flow) to deliver value to the customer in a predictable way (teams of teams). Removing traditional delays and overhead enables lean prioritization of work to be delivered to the customer in small batches with regular short feedback loops to validate the value and shape future work.
  • Funding Traditional Projects requires phases and gates (start and stop) pattern of delays to prepare and approve milestones along the way, building up delay in value and longer feedback loops. This also results in rework that adds further delay in the project. This is an anti-pattern to Lean-Agile and stifles momentum on multiple levels, introducing costs as delays.

A realization that emerged from training and I’ve been able to reflect on, is that these approaches address very different parts of the iron triangle.

  • Funding Value Streams fixes the TIME corner of the iron triangle, where if QUALITY remains fixed then the COST corner has to give.
  • Funding Traditional Projects fixes the COST corner of the iron triangle, where if QUALITY remains fixed then the TIME corner has to give.

Agile hypothesis-driven business development feeds a funnel of small changes and fast feedback loops to the business. This approach enables the company to develop solutions to customer needs incrementally and adjust along the way.

  • Funding Value Streams enables forming an hypothesis for adding value, sizing the effort to prove the hypothesis, and sampling the hypothesis with customers along the way.
  • Funding Traditional Projects assume a model of completing all the work to prove the hypothesis before delivering the solution to the customer for feedback.

Further, the company needs to shift how it views governance in this new world. The management constraints shift from project-progress based to value-delivered based, and therefore the KPI’s (key performance indicators) for measuring success of the business shift as well. The traditional PMO team transforms to an “Agile PMO team” that drives this new governance model.

  • Funding Value Streams KPI metric examples
    • Program Increment Objectives – Business  Value (plan vs. actual)
    • Predictability of velocity and volatility as points completed in each sprint
    • Throughput (time to deliver value from concept to customer use)
    • Hypothesis tested vs. hypothesis failed over time
  • Funding Traditional Projects KPI metric examples
    • Cost Performance Index and Cost Variance (on-time and within budget)
    • Missed milestones and % tasks complete
    • Resource utilization
    • % cancelled projects

These concepts are very important to consider before starting on the Enterprise journey of scaling agile. It means all the executive leaders of the company need to go through this training to realize this shift has to take place. These executive leaders then form new strategic themes and initiatives that are the basis for funding these value streams of agile teams. When this happens, then the company can truly transform to a Lean-Agile organization. Only then can the company strive to high performance.


Agile Defect Prevention | Part 2

June 24, 2012 2 comments

Continuation of

So you have your escaping defects under control and your team is looking to optimize further to become an elite agile team…what more can you do towards defect prevention? Just as WIP Defects (‘Work In Process’ Defects) are an antidote to Defects, TDD (Test Driven Development) is an antidote to WIP Defects. WIP Defects, although a great way to contain faults from getting into the customer hands, is still an anti-pattern to elite agile teams. These teams are test-infected and write more tests than application code, and catch most problems while authoring the application code.

Fine Craftsmanship

In an elite agile team, everyone writes and executes tests. Product Owners carefully craft use cases with well thought through acceptance criteria, and regularly validates both that the working application behaves as intended and is a delightful experience. Software Engineers write unit tests to assure solid code craftsmanship, performance tests in the sandbox to assure efficient basic application behavior, and manually inspect their user experience like a fine cabinetmaker inspecting the glide action of the drawers in the cabinet he is building. Quality Engineers work closely with the Product Owner to understand the intent of the features, and with the Software Engineer to understand the design and share test approaches, authoring and running tests along the way. Quality Engineers peer inspect tests with Software Engineers so that both are intimately familiar with the tests. Both Software and Quality Engineers regularly run unit and regression tests, and validate both performance and user experience in each context the application runs in.

Consider writing failing test cases instead of WIP Defects as a start down this path. I have found that Quality Engineers who are not use to developing tests early and conducting peer inspections of tests with Software Engineers, are initially uncomfortable by the idea of not writing defects. You need to document the defect somehow. The best documentation is the regression test and not a defect report. This will foster correcting the problem promptly as a failing test instead of a WIP Defect hand-off or scheduling an escaping Defect fix. Get into the habit of running regression tests for the feature being worked on often throughout the day in the sandbox environment, with visibility by the whole team, as part of the CI (Continuous Integration) cycle.

Measure cycle time and efficiency in defect prevention over defect counts. You may still need to track defect counts, fix/find rates, etc. (especially in a larger organization), however in an elite agile team these defect counts are so small that everyone in the team is aware of them. Defect prevention and correction are part of the cycle time to deliver the changes. Take the time to be clear on acceptance criteria, compatibility with standards and architecture, and stability of the code changes. Collaborate within the team such that progress on code design and development, and the tests to validate them, is well known. Elite agile teams write and execute the tests early and often that assure working software remains working.

Even in elite agile teams there are Defects that a found late in the iteration or are a larger problem than can be solved at the time of discovery to fix prior to declaring work done. This warrants creating an escaping Defect. The elite agile team carefully scrutinizes each escaping Defect for defect tolerance of the business and impact to the customer, before opting to let the escaping defect into the field. The intent of the agile life cycle is to add business value often, and in small enough iterations to foster continuous feedback, so it might be more important to deliver the change with the defect than delay delivery. An escaping Defect may survive past an iteration and still be held back to release into the field until fixed in another iteration.

Elite agile teams continually test with constant feedback of pass/fail results. There are no unknown failures left without attention to understanding the problem as it is introduced. Problems are corrected promptly and not let into the field for exposure to customers. The whole team is aware of test status through continuous integration practices. There are very few, if any, known defects in the field.

Agile Defect Prevention

September 23, 2011 1 comment

I recall a day in the late ’90’s when assessing readiness for deployment of an application at Kodak after a several month long release cycle having 3,000 deferred defects. WOW! I can’t believe that was acceptable at that time, but in long waterfall release cycles that was the norm at the time. How can you manage defects like this? Today, this is unacceptable. The idea of “deferred defects” has always bothered me in software development. So, what can we do about this?

No BugsAlong comes agile software development cycles where a defect backlog is an anti-pattern (No Bugs). The idea is that through continuous integration, unit tests, early inspection, and regression tests, your team finds problems as they are introduced. This is great in theory, but how do we manage the inevitable defects that we can’t get to and is an acceptable risk to meeting business requirements, and those defects that will come in from the field as support requests to fix? My approach to managing this is to focus on “defect prevention” as opposed to “defect tracking.”

Defect prevention, really? …is that possible? Imagine counting defects on your two hands. constraining escaping defects to what fits on your two handsHow can we accomplish this? Efficient agile organizations focus on defect prevention rather than downstream defect discovery. A culture of defect prevention includes separating “work in process”  defects (WIP Defect) from “escaping” defects (Defect) to minimize defect management that escape beyond the sprint that features are developed in. This results in a much smaller defect backlog to manage and dramatically increased customer satisfaction. Agile is not just about releasing more often, but also with complete and tested features. So, we need to treat defects found in development as actionable sub-tasks of the feature work item. If we treat these WIP Defets as sub-tasks and acceptance criteria of completing the development tasks, then we are not introducing them to the field and not adding to the project team backlog as technical debt.

Escaping defects should then be treated as ranked backlog work items, along with other project work items. They should be prioritized high enough to resolve them within the next sprint or two and not accumulate a growing backlog. Watch the defect backlog as part of the project metrics. A growing defect backlog is a key indicator that the team is taking on more new work than it can handle. It may also be a key indicator that the team is operating as a “mini-waterfall” project, rather than a agile project, requiring more collaboration between Dev and Quality Engineers and early testing. Drop the number of new items the team works on until the escaping defects are well managed or eliminated.

When a WIP Defect must exist past the completion of the parent development task, then promote it to a Defect and place it in the backlog in rank order with other work. However, whenever possible the team should heavily scrutinize this practice and opt to hold delivery of the feature until the WIP Defects are complete. Also, a Defect in the backlog could be demoted and attached to an active development task to include it in the acceptance criteria for that task.

At Constant Contact, we now have our defects in the same tool (Jira/GreenHopper) that we manage new feature work, such that defects are in the same project and iteration backlogs. This provides greater visibility to the product owner ranking the work and the team implementing the work.


November 20, 2010 Leave a comment

Scrum works well to well when there is a distinct backlog of prioritized work and distinct time-boxed release cycles. Scrum scales well with a Scrum-of-Scrums group where scrum masters scrum across teams, provided you introduce program management to oversee the progress across teams. As an organization grows in agile product teams that align with a single delivery cycle, agile service teams emerge (e.g. Engineering Services, Database, Application Operations, automation infrastructure, etc.). Many of these teams have both planned backlog work and on-demand unplanned work (work request tickets).

Scrum is a push model where work is pushed into the team in prioritized order. Many times work on an item may be blocked by a dependency on another team, so the team picks another work item to work on, and so on. This leads to many things started without being completed and accepted in an consistent flow throughout the length of the sprint. The result is a lot of task switching and inefficiencies near the end of the sprint to get the work done in the sprint, and technical debt (deferred defects, refactoring for reuse, etc.). This is especially difficult when you have many interdependencies between scrum teams.

There are three key challenges that emerge as you scale these needs:

  • minimizing work in process (WIP) with smaller work items
  • balance the planned and unplanned work and their priorities
  • minimize bottlenecks in the flow of work

Kanban is another agile concept borrowed from the lean principles of the manufacturing industry in Japan. Kanban (or kamban in Hepburn romanization–kanji 看板, katakana カンバン, meaning “signboard” or “billboard”) is a concept related to lean and just-in-time (JIT) production. According to Taiichi Ohno, the man credited with developing JIT, kanban is a means through which JIT is achieved ( Kanban is a pull model, rather than the push model of Scrum. It uses the same idea of a user story broken into work items with tasks attached. It uses the card (sticky note) concept as in Scrum, but it uses the idea of clarifying distinct process steps (columns) and swim lanes (rows), where each step has a distinct WIP limit. You still have a prioritized backlog to pull work from. Each swim lane has a purpose for processing work, and each step can only pull work from the previous step once a work item or task is pulled from the downstream step. If the downstream step does not have capacity you can’t push the work to them. This leads to tuning the efficiencies and capacities in each step to accommodate a cadence of pulling work through the swim lanes.

Constant Contact (CTCT) is moving from Scrum to Kanban to address these needs. Mike Fitterman (Development Manager) and Rick Simmons (Agile Coach) illustrate the learning of the pilot team (website) at Constant Contact, as presented at the Agile2010 conference: AgileConference2010-Upstream_Kanban_at_CTCT. At Constant Contact, we have nearly all (both product delivery and service) agile teams using this approach at the time of this writing. You can see Kanban boards in many of our conference room and work area walls as you walk through the engineering space. The Scrum-of-Scrums still occurs daily, however it is more focused on larger project progress, interdependencies, and organizational impediments. We are still working out our inefficiencies with this new process, but it seems to be working well for us so far.

Kanban Board

Constant Contact Website Team Kanban Board

Kanban addresses the need to minimize the WIP by constraining each step in each swim lane. It allows for an express lane for high priority on-demand unplanned work (defects and footprint tickets). It makes inefficiencies and bottlenecks apparent to the team to self-correct and tune how the work is done at each step (colored sticky notes and visible policies). Overall it smooths out the cadence of work to keep work flowing through the team with visible status of all work items to the whole team.

Visit to explore more about Kanban agile practices, references, training with David Anderson, founder of Kanban as a software development practice.

Nokia Test: Are you really agile?

December 19, 2007 Leave a comment

I have recently had discussions with several management colleagues about agile and find that most are not really getting far enough to realize the full value of agile. Jeff Sutherland and many other champions for the Scrum model presecribe the Nokia Agile Test as a litmus test to deterimine if a team really is agile. This test was developed by Nokia internally to assess development teams at Nokia and their partners. Nokia has the largest number of certified ScrumMasters in a company in the world today.

Nokia first determines if the team is able to abopt Scrum by determining if they are doing iterative developement.

  • Iterations must be timeboxed to less than six weeks
  • Software must be tested and working at the end of an iteration
  • Iteration must start before specification is complete

Next, the Nokia Scrum Test…

  • You know who the product owner is
  • There is a product backlog prioritized by business value
  • The product backlog has estimates created by the team
  • The team generates burndown charts and knows their velocity
  • There are no project managers (or anyone else) disrupting the work of the team

I would also add some items to the list…

  • The story includes clearly defined acceptance test(s) [validates requirement complete]
  • The accpetance test(s) are automated, part of the code base, and run as a regression suite on a regular basis
  • The story is not fully complete (implemented) until the acceptance test(s) are automated

The bottom line is that there are many companies that think they are doing Scrum, but aren’t really and are plagued by legacy processes and measures. It is fine to take small steps to migrate your organization to agile, but keep going until you really get there.

Categories: Agile, Scrum Tags: ,
%d bloggers like this: