Posts Tagged ‘Big Agile’

What’s Next for the Agile Manifesto

Posted on February 13th, 2011 by Dennis Stevens  |  11 Comments »

This weekend, about 33 people got together at the Snowbird Cliff Lodge to celebrate the 10th anniversary of the Agile manifesto. This group was invited and hosted by Alistair Cockburn. The goals were to have a celebration, talk about the successes achieved and the problems facing the community, and hopefully contribute something back around the problems that we can sensibly address.

This is not a replacement or an extension for the Agile Manifesto. It is more of a focusing statement relevant to our understanding of today’s problems and needs. There was a lack of alignment at some levels – although the expected disconnects, Kanban vs Scrum vs XP or whatever, didn’t arise. The biggest lack of alignment I saw was between those that feel we need to address Agile across the business and the group that believes Agile is about only software development, asking “Who are we to be describing how the organization should be designed?” I believe this gap has at it roots the different perspective of the people who attended. Some work within software development teams. Some help organizations adopt Agile. And some help organizations exploit the Agile ability to rapidly deliver working increments of value to update business models and deliver on new value propositions.

But there was a ton of alignment on some issues. There was great energy and flow in the room. There was some negativity and cynicism that came from our focus on what problems exist. But that was the exercise – identify problems that we can sensibly address. I found the entire weekend to be valuable and enjoyable. And I believe we came up with something of value as well.


The facilitators had identified seven categories of questions or issues that had been identified through pre-session interviews with some of the attendees.

  • The Future
  • Training
  • Technical
  • Culture
  • Enterprise / Other Communities
  • Value
  • Agile Backlash

After an initial group warm up, we broke into seven groups with each being assigned to an area. We worked to identify the gaps or issues that need to be addressed in the industry today in our assigned area. We then we rotated around the room in our teams to review the other areas, adding any additional issues we identified and moving some issues from one category to another. We then went back to our original categories and identified underlying themes from the issues. These became the big problems that needed to be addressed. This was great conversation within our groups and the underlying themes were pretty clear and consistent. We then did a read out of our themes to the bigger group and had some additional discussion.

Then we took a five hour break.  Some people stayed and did more work, some napped, some when skiing. I went up on top of the mountain with Alan Shalloway, Joshua Kerievsky and Ahmed Sidky. The view was awesome and I really enjoyed the company and the conversation.

When we reconvened and worked to consolidate the big problems under the following headings.

  1. What problems in software or product development have we solved?
  2. What problems are fundamentally unsolvable?
  3. What problems can we sensibly address — problems that we can mitigate either with money, effort or innovation?
  4. What are the problems we don’t want to try and solve?

We then grouped the problems under “What problems can se sensibly address” into themes and dot voted to identify the biggest issues. Finally, we worked to craft a sentence to address the four top themes. This became a challenging process as there were 30 strong willed people with different perspectives all trying to influence the sentences. As we narrowed this down through our consensus process there was a lot of discussion and debate. At the end of the allotted time we had the following.

We, the undersigned, believe the Agile community must::

  1. Demand Technical Excellence
  2. Promote Individual Change and Lead Organizational Change
  3. Organize Knowledge and Promote Education
  4. Maximize Value Creation Across the Entire Process

Demand Technical Excellence

At the end of the day, you can’t deliver value through technology if you are not delivering quality. This category brings in aspects of architectural, engineering, and design. This is still a pressing issue and must be addressed in the community to deliver on the promise of the Agile Manifesto.

Promote Individual Change and Lead Organizational Change

Here is an example of a sentence that we had a broad range of perspectives on. Without adoption by individuals and alignment of organizational governance and management models, Agile won’t deliver on its value proposition.

Organize Knowledge and Promote Education

This isn’t just about the practitioners, it includes the broader business context as well. The community needs to build on the broad body of knowledge that exists within and outside the community – we have to avoid reinventing everything. Diversity of thought is important to the ongoing growth of the community – but we don’t actually do a very good job of intentionally building on the body of knowledge.

Maximize Value Creation Across the Entire Process

Software Development is not an end unto itself. Too many organizations moving toward Agile are focused on just the software development team. This is only valuable to the point that the software development team is the constraint in the organization. We need to learn how to do a better job of defining value and aligning the cadence across the organization and improving the flow of value from concept to delivery.

Closing Thoughts

This was a dynamic crowd with a lot of experience. In this group, there was very little contention between flavors of Agile. Everyone was open and working to address the needs of the industry and the broader needs of the communities we live in. There are lots of problems – I am sure there will be a lot of talk about “The Elephants” – problems that didn’t explicitly make the list. There will be some dissenters. And I think there may be some work to refine the sentences. Hopefully without losing the meaning of the points.

I believe that Alistair’s goals were achieved. We had a nice celebration – we came to consensus (although not unanimous agreement) on the big issues in front of us. And we shared a lot of energy and community. I got to meet and develop relationships with a number of amazing people. And we ate and drank a lot both nights. I don’t know what comes out of this effort in the bigger community. Now, let’s see how the Agile community responds to the outcome.  I hope we rally around the big issues and continue to improve where we work and the value we deliver.

10 Years Agile–Friday Night

Posted on February 12th, 2011 by Dennis Stevens  |  3 Comments »


Here are the people that are in Snowbird for the 10 years Agile celebration.

  • Pekka Abrahamson
  • Scott Ambler
  • David  Anderson
  • Mike  Beedle
  • Tracy Bialik
  • Alistair  Cockburn
  • Rachel Davies
  • Michael Feathers
  • James Grenning
  • Robert Holler
  • Jonathan  House
  • Erik Huddleston
  • Michael Hugos
  • Zhon Johansen
  • Kay  Johansen
  • Ralph Johnson
  • Nate Jones
  • Joshua Kerievsky
  • Jon Kern
  • Phillipe Kruchten
  • Janice Linden-Reed
  • Todd Little
  • Ryan Martens
  • Eric  Olafson
  • Jeff Patton
  • Russ Rufer
  • Alan  Shalloway
  • Ahmed  Sidky
  • Andrew Shafer
  • Dennis  Stevens
  • Jeff  Sutherland
  • Arline  Sutherland
  • Ghennipher  Weeks

Friday Morning

I spent the morning with Ahmed Sidkey and Alistair Cockburn working on some ICAgile activities. We are trying to get the Business Analysis and Project Management tracks up now that Agile Fundamentals has launched. I am working with the Business Analysis community to coordinate the BA track and bringing the PM work from the recent (and ongoing) efforts of Alistair, Ahmed, Mike Cottmeyer, Mike Griffiths, Michelle Sliger, Jesse Fewell and others with PMI to define Agile PM.

Pre-Cocktail Party

After riding up to the conference, I got to meet and spend time with Tracy Bialik, Alistair, Ahmed, David Anderson, Alan Shalloway, Janice Linden-Reed, Phillipe Kruchten, Erik Huddleston and others greeting, catching up and talking about our expectations for the weekend.

Cocktail Party

At 8, we had a cocktail party where we met Janet Danforth and Robert Moir. Janet and Robert will be facilitating the Saturday morning discussions. There were questions spread around on tables that had been solicited from attendees by the facilitators prior to the event. They were divided into several categories for us to review and discuss. I spent some time at a table with a number of people including Ahmed Sidkey, Jon Kern, Erik Huddleston, and Scott Ambler. The discussion started off around how to get other communities (BA, PM, QA, etc) involved in the Agile. We ended up talking about resting heart rates and food densities – so while it was interesting at the moment I’m not going to blog about it here.

I then spent about half an hour in a discussion with Erik about his approach to scaling agile at his organization. He has courageously built on Dean Leffingwell’s model. He is implementing small fungible teams (high performing teams with the ability to deliver a working increment of software across the portfolio) and is using Kanban at the Program level to feed and coordinate the teams and to dynamically match capacity to demand. Then he is using Kanban downstream from the teams to coordinate integration testing, implementation, and production. This is a pattern that I have seen work well and have seen emerge from multiple directions. Mike Cottmeyer and I have been using this model as a kind of reference architecture for businesses and have had success. I believe this is an organizational adoption pattern that we will see more of.

Later I was involved in conversation with Jeff Patton and Rachel Davies talking about various topics. One was how hard it is to define explicitly how to apply certain practices when coaching teams since we tend to morph them to the moment and are always applying new concepts and ideas. Jeff is gently introducing A3 type thinking into his clients – something that we are starting to do more of – so it’s a validation of a pattern that makes sense. Jeff and I talked about how capability analysis and story mapping share some underlying patterns that seem to make sense. Rachel talked about how hard it is to to get organizations to change and how organizations seem to get stuck in destructive behavior. Jeff brought up this video as something he shows in his class to help people to recognize how they participate in their organizational dysfunction. It is pretty funny.

After Party

We had an after party from 9:00 – 11:00 where we drank Cockburn port and had more conversations. I spent some time talking to Alistair and then got to spend a while with Joshua Kerievsky and Mike Beedle talking about how important the underlying enabling technologies were to doing anything agile.  We also talked about how Scrum and XP have morphed and how implementations must be situation specific.


There are a lot of people here from various communities. Lean, Scrum, XP, etc. It would be fun to do social network map of who is connected to who in this group and what those communities look like. There was a lot of engagement and energy last night and I didn’t see any conflict. The themes of post-agile, situation specific morphing of practices, and scaling patterns were pretty common place. Today, we have a four hour facilitated session that should be interesting.

We are Doing QA All Wrong

Posted on August 23rd, 2010 by Dennis Stevens  |  17 Comments »

Over the last month I have presented or participated in several user groups and conferences. There was Southern Fried Agile in Charlotte, Agile 2010 in Orlando, a PMI Atlanta professional growth event, meetings of Agile Atlanta and the Atlanta Scrum Meet-up, and Product Camp Atlanta (not surprisingly in Atlanta). These conferences give me an opportunity to meet with people doing, or attempting to do agile in the enterprise. There are a lot of common patterns that I am seeing. One of the most common patterns is that we are doing QA all wrong in most companies.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

  • the cost of setting up testing environments is much lower
  • our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
  • our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.


Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

  • Switch their primary focus to Quality Assurance
  • Help the organization reduce re-work
  • Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
  • Enable value, flow, and ongoing improvement
  • Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?

Making Agile Requirements Work-No 4

Posted on November 3rd, 2009 by Dennis Stevens  |  No Comments »

We have proposed that Agile Requirements must be built at a purpose and outcome level, must leverage shared language that communicates context and intent, and must be based on a stable view of the domain. But even with these in place requirements can still fail to support the way people solve problems and the way people learn. When we try to be to prescriptive and communicate too much detail initially it will reduce effectiveness – not improve agility.  Agile requirements must support progressive elaboration.

Don’t Support Progressive Elaboration

One of the faulty assumptions made in Requirements Elicitation is that we believe we can know up front exactly what we want. It is also faulty to believe that we should document requirements in too granular detail. In fact, neither of these is accurate. Requirements should support the concept of progressive elaboration. That is, they should be documented so that more specific detail unfolds during the course of the project. This addresses the flaw in both of assumptions. First, documenting what we know at a high level of detail allows us to establish a consistent context that we can communicate in more detail the more we learn. Getting to too much detail early can result in rework and inconsistency in communication.

Agile teams may break requirements into Themes, Epics, Stories, and then Tasks. This may be hierarchical, follow a story-map, or be connected in a mind-map.  Themes are be defined early on and directly connected to business value propositions. These are then progressively elaborated into Epics and Stories as needed to feed the team. As Stories move into a ready state for development they can be further broken down into tasks by the development team. This progressive elaboration allows the team to apply what it learns about the best way to deliver the project as the project unfolds. Critically, it also supports the way that people learn about the problem. Too much detail early on can be overwhelming and result in a disconnected or inconsistent understanding of the effort. Not enough detail later on results in a lack of shared understanding of the problem. Progressive elaboration supports effective communication, collaboration in solution finding, and the application of what the team learns as the project unfolds.

Understanding the Customer vs Customer Value

Posted on November 2nd, 2009 by Dennis Stevens  |  2 Comments »

The Gilb’s have started a series of posts against Agile. The first on is Wrong Focus.

“It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user. It is all about delivering, to your set of Stakeholders, value improvements to them, to what they care about, what makes their world better, within agreeable, minimum or pre-determined costs. If that is not the main focus, if that is not clear to everyone on the team, you will eventually loose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.”

They claim Agile software development is flawed because it focuses on improving the process and environment of the team developing software. These improvements result in improved customer collaboration that ensures the team better understands what the customer wants. From my experience, the combination of improved environment, appropriately sized process, and customer collaboration results in mature agile teams doing a great job of delivering the projects and products. But I understand their point. There is a difference between understanding the customer and focusing on delivering customer value.

Wrong Focus

Whether the software development organization is building software for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business. In any of these improvements, there is more improving that is valid than is necessary to achieve the benefit. If the team works on improvements that aren’t the focus of the effort, “while they are there”,  they are not focusing on business value. This delays delivery of the effort and is not the right investment for the business.

Nothing in the Agile Manifesto, nor most of the Agile methods, give the tools to pick the right improvements to focus on. They also create an environment where it is extremely likely to work on more then is the minimum necessary to achieve the targeted business benefit. In many organizations, close customer collaboration can lead to “gold-plating” of features. If you offer the customer whatever they want – they will ask for it.

Wrong Focus in Practice

I have a customer right now that is going to build some software to support their field employees. The business goal is to achieve a significant cost reduction in the field through improving quality and efficiency in the field. The developers are extremely interested in developing mobile applications, distributed collaboration, GPS interfaces, image capture and markup, mapping, barcode, and training training. They have started a new business to build this product with the hope of selling it outside the business in the future. The challenge here is how do they clearly identify those improvements in the field and in dispatching that will deliver the significant reduction in field expense. If they go and and talk to the dispatchers they might find 30 things that could be done better. All of these improvements would result in an improvement in work conditions or performance. But they may not be aligned with the current business focus. The same will happen in the field.

Just because it will improve satisfaction or make someone’s job easier doesn’t mean it will help with the current business focus. How do they align absolutely the minimum amount of technology to deliver on these improvements? Especially when their interests are in this bigger, more robust solution. Especially when this limiting of features is not in line with their future business objectives. Nothing in Agile addresses how to deal with this conflict.

Where’s the Answer

I address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract this from the team. They focus on improving their processes and collaboration. In Scrum, Business Analysis is abstracted behind the Product Owner. In XP, it is abstracted behind the Onsite Customer. I don’t agree with the implication from the Gilb’s that this abstraction is a deficiency in Agile. It is just outside the scope. I also don’t agree with Agile teams that close collaboration with the customer is sufficient to ensure business value is achieved. This is not an OR conversation. This needs to be handled as an AND conversation. This is the next thing we need to learn – how to keep an Agile team laser focused on business value AND maintain the benefits of understanding the customer that comes with Agile software development.

Making Agile Requirements Work-No 3

Posted on October 29th, 2009 by Dennis Stevens  |  No Comments » defines a requirement as “that which is required; a thing demanded or obligatory”.

BABOK® is consistent with this. It defines a requirement as:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

The purpose of documenting requirements is not to document detailed steps that someone performs – it is to communicate the outcome needed to achieve an objective. One problem that arises is when requirements are expressed as a document of the existing process – typically through a review of existing process documentation or through observation of people doing the job. As I have discussed in previous posts, just documenting process can lead you into the How Trap and it can fail to generate a useful shared understanding. These problems arise when the focus is on how stakeholders are currently doing the work and not on understanding the challenges, problem or objective.  But, focusing on process is a problem in another way. It is an unstable lens.


Modeling processes early in the elicitation process is not helpful to creating an appropriate understanding of the effort. Process reflects how people say they ought to do a task in perfect circumstances. The work is almost never consistently performed based on process documentation – or even how you observe the process being performed. Exceptions, reorganizations, changes in personnel within or adjacent to process, new tools and technologies, and innovation will change the process view. Even just asking five different people what the process is will likely produce five different results.

The process view can also propagate flawed understanding on the part of the people doing the work. You have likely heard the story about the recently married young women who was cooking her first Thanksgiving dinner in her own home. She had invited her family over the beautiful house she shared with her husband to show her parents how successful she had become and to demonstrate her gratitude to her parents. As she brought out the turkey for dinner her mother noticed the young women had cut the tail off of the turkey. The mother asked her daughter why she had cut the tail off the turkey. “Because that’s they way you always did it, Mom.” The mother smiled and replied, “That’s because the only pan we owned was too small for the turkey.”

A process based view hides assumption, complexity and is an unstable representation. The real requirement doesn’t change based on who you ask, who is doing the job, or the most recent reorganization. Basing requirements on unstable views doesn’t reflect the intent of the solution. This may result in an expression of the solution that doesn’t meet the needs of the business. As you observe a process or review process documentation ask why each step is important and what the intent of each step is. Consider what would happen if the steps were done in a different order or something was left out. Creating a stable, purpose driven view of the objective will provide valuable input to the development organization that will result in an improved solution.

Making Agile Requirements Work-No. 1

Posted on October 26th, 2009 by Dennis Stevens  |  No Comments »

The problem with many current methods of Elicit Requirements on software development projects is that they don’t add economic value to the solution effort. Many projects develop unrealistically detailed requirements in large batches up front. Due to the impossibility of accurately defining exactly what the effort requires they aren’t completely useful. In addition to resulting in churn and rework they require a high level of effort to maintain. In response to problems with Big Up-front Elicitation efforts some projects have resorted to “too little” requirement definition up front. This also results in expensive churn and a lack of project focus that delays the time to value. In both cases the transaction costs associated with producing and maintaining the documents offset any value they might bring.

The How Trap

The How Trap is a very human condition. If you see someone at the fax machine and ask them what they are doing, they will say “Sending a Fax”. That isn’t what they are doing though. That is “how” they are doing something – not what they are doing. The How Trap is very common. Ric Merrifield, in his book Re-Th!nk: A Business Manifesto for Cost Cutting and Innovation talks about Dick Fosbury and the Fosbury Flop. Dick Fosbury realized the How of the high jump was to go as high as possible and abandoned trying to perfect any of the existing techniques that involved jumping over the bar so you could land on your feet. His focus on the What of jumping as high as possible led him to jump over it backwards and land on his back. His gold medal in the 1968 Summer Olympics pointed out the wisdom of his approach. When requirements are elicited on a How-Trap basis assumptions are made that limit options that should be considered to accomplish the goal of the effort.

To avoid the how trap elicit requirements based on outcomes and purposes. Avoid getting trapped in How specific language. You can be pretty specific about the purpose or outcome without falling into non-productive detail. For example, the outcomes and purposes associated with Pay Employees doesn’t change much regardless of the implementation. People need to be paid a specific amount, there are specific tax requirements, and there are clear governance and compliance needs. These don’t change whether Pay Employees is outsourced, done manually, or automated internally.

Remember Fosbury’s goal was not to jump higher it was to clear the bar at its highest point. Sending a fax is never the requirement. It is something like Communicate Status or Confirm Order. This is a subtle distinction but frees up the team to apply their creativity to the How and will lead to significantly different outcomes.

Requirements Management and Communication

Posted on October 19th, 2009 by Dennis Stevens  |  No Comments »

Today I am discussing the tasks from the BABOK associated with Requirements Management and Communication. These are the tasks Ensure knowledge gained through business analysis activities throughout the effort is shared among the team. There are six tasks associated with Requirements Management and Communication. I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Requirements Management and Communication: BABOK® Tasks

Prioritize Requirements

Purpose Agile Impact
Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. In Agile, requirements are progressively elaborated. Throughout the Elicitation Task, Elicitation results are progressively broken down and elaborated. At each point of elaboration the constituent parts need to be evaluated and prioritized based on business value contribution and risk burn-down.  In Agile, this is not a one-time up front activity. This happens throughout the life of the project on all remaining work and new work brought in from learning about the product.

Organize Requirements

Purpose Agile Impact
The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. In Agile, it is important to organize requirements to minimize dependencies between feature sets. This reduces complexity and risk and improves testability at the business level value. Since requirements are progressively elaborated, this big block architecture results in the Solution Architecture from a business standpoint. Requirements should be organized around business value – and not technical implementations. Only within component teams – where the business value arises from delivering enabling technology – is it appropriate to depict technical requirements. Even then, these requirements need to be prioritized and filtered based on risk burn down and business value contribution. Story Maps within Epics are a method of implementing Organize Requirements.

Specify and Model Requirements

Purpose Agile Impact
To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. At different levels of elaboration there are different methods for specifying and modeling requirements. The approach should support progressive elaboration, is adaptable to change based on learning, and doesn’t box in the team to solutions too early.  It should also ensure that intent and intended business value is communicated consistently through the elaboration.  Agile teams tend to use Stories and Tasks at the lowest level of decomposition. These Stories and Tasks can be supported by detailed documentation and use cases. It is becoming increasingly common for acceptance tests to be produced as part of specifying and modeling the requirements.

Define Assumptions and Constraints

Purpose Agile Impact
Identify factors other than requirements that may affect which solutions are viable. On Agile projects this is handled through a risk management approach that treats risks as stories within themes. Risk mitigation activities are prioritized along with stories and burned down and re prioritized as they stories are performed. This is typically produced by the business analyst and project manager along with the team, prioritized by the product owner, and performed by the team.

Verify Requirements

Purpose Agile Impact
Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work. Requirements are verified by the team during the project. Through retrospectives and operations reviews the team may decide to modify the level of detail to or the method of specifying and modeling requirements to improve the performance of the team.

Validate Requirements

Purpose Agile Impact
The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need. Requirements are verified throughout the development and delivery of the solution through continual involvement of the product owner and customer. This happens at release planning, iteration planning, during development, and at customer acceptance.

Agile Requirements Management and Communication

All of the tasks in Solution Verification and Validation are important on Agile projects. The primary distinctions in this Knowledge area are the support for the emergence of the solution over time. Particularly interesting are Assess Organizational Readiness and Transition Requirements as these are often overlooked in Agile projects (many software development projects). Remember, the product isn’t done-done until the customer is using it and achieving the benefits expected by the product owner.

Agile Business Analysis Enterprise Analysis

Posted on October 15th, 2009 by Dennis Stevens  |  No Comments »

Today I am discussing the tasks from the BABOK associated with Enterprise Analysis. These are the tasks to understand what the enterprise is capable of performing. There are five tasks associated with Enterprise Analysis. Again, I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization

Task: Define Business Need

Purpose Agile Impact
The definition of the business need is frequently the most critical step in any business analysis effort. The business need defines the problem that the business analyst is trying to find a solution for. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated. In mature Agile projects, the business need is determined up front by the Product Owner. This happens on an Agile project in a similar fashion that it happens on non-Agile projects. However, during the course of the effort, the business need is continuously reviewed and updated as appropriate.

Task: Assess Capability Gaps

Purpose Agile Impact
To identify new capabilities required by the enterprise to meet the business need. On an Agile project, this occurs not just at the start of the project – but throughout the project in retrospectives and operational reviews. This is not performed by the Business Analyst, but is performed cooperatively by the team.

Task: Determine Solution Approach

Purpose Agile Impact
To determine the most viable solution approach to meet the business need in enough detail to allow for definition of solution scope and prepare the business case. Agile development provides a faster delivery of value than traditional methods. It also supports incremental delivery so the Solution Approach can be evolved over the course of the project. This approach allows a different bargain to be struck with the business regarding determining the solution.

Task: Define Solution Scope

Purpose Agile Impact
To define which new capabilities a project or iteration will deliver. The Scope of Agile projects evolves during the course of the project as the team learns more about ways to solve the problem and the customer preferences for a solution.  The scope is defined in higher level abstractions (themes, epics, etc) and is detailed as the project evolves.

Task: Define Business Case

Purpose Agile Impact
To determine if an organization can justify the investment required to deliver a proposed solution. The business case for Agile projects are typically based on achieving a specific business outcome within a specified cost and time.  The business case is revisited frequently as the team learns what it can deliver, how well it meets the real (not perceived) needs, and whether the business outcome can be achieved within the specified cost and time.

Enterprise Analysis Agile Summary
All of the tasks in Enterprise Analysis are important on Agile projects. The primary distinctions in this Knowledge area are contributing to the continuous improvements of the organizations ability to deliver as well as the emergence of the business need through the project.

Agile Business Analysis Elicitation

Posted on October 14th, 2009 by Dennis Stevens  |  1 Comment »

Today I am discussing the tasks from the BABOK associated with Eliciation. These are the tasks to Understand the underlying needs rather than stated or superficial desires. There are four tasks associated with Elicitation. Again, I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.


Task: Prepare for Elicitation

Purpose Agile Impact
Ensure all needed resources are organized and scheduled for conducting the elicitation activities. Preparing for Elicitation changes during the life of the project. Early on, it is done by the Product Owner (Business Analyst) to coordinate supporting materials and schedule resources to define the high-level requirements. This is coordinated by the Business Analyst. As the project progress, work is coordinated by prioritization of the backlog. The customer will be pulled in to work directly with the developers on a frequent (daily) basis to elaborate requirements.  This task requires the scheduling of resources and the coordination of inputs to align with the progressive elaboration of the backlog.

Task: Conduct Elicitation Activity

Purpose Agile Impact
Meet with stakeholder(s) to elicit information regarding their needs. Early on, Conduct Elicitation is performed by the Product Owner or Business Analyst to define high-level requirements. As the project progress, the customer interacts with the development team directly during iteration planning and even during development. At each step the requirements are further decomposed to smaller units of business value. Finally, the customer interacts with the developers on a frequent (daily) basis to elaborate the requirements.

Task: Document Elicitation Results

Purpose Agile Impact
Record the information provided by stakeholders for use in analysis. The amount of documentation is a key distinction between Agile and traditional efforts. Early on, the Business Analyst will document elicitation results at a high level – with enough detail to communicate intent and value. The results will be gathered into a backlog that will be developed in more detail as the project progresses. At the end, the developer may make changes during interaction with the customer that invalidates the documentation. One of the tenants of Agile is “Working software over comprehensive documentation.” The code becomes “self-documenting.” The team must decide how to reconcile the difference between historical documentation and the working product.

Task: Confirm Elicitation Results

Purpose Agile Impact
Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs. This happens by the Team during iteration planning , during the development iteration, and at Customer Acceptance. The customer may change her mind about some specific element of a story after they have seen the result.  This feedback becomes an input into the conduct elicitation activity.

Elicitation Agile Summary
All of the tasks in Elicitation are important on Agile projects. Again, the primary distinctions in this Knowledge area are planning for  continuous engagement with  the customer and the progressive elaboration of requirements. In the event that the enterprise has governance requirements or there are contractual obligation, the team will have to negotiate how they will deliver documentation that is sufficient to support the needs of the business.