Increasing Business and Technology Throughput

Over the last few weeks I've been posting ideas on to effectively manage each discipline within a project using a combination of Agile and Unified Process techniques in order to optimize the 'throughput' of business ideas into high quality software.  Today I'll spend some time on the Testing discipline which ensures that a high quality solution is being provisioned.

Iterative Testing:  A Paradigm Shift

One of the first steps in developing an effective iterative testing approach is recognizing some of the areas that it differs substantially from more traditional testing approaches. A paper I wrote serveral years ago called Managing Iterative Testing in an Agile Development Project provides some practical guidance in considerably more detail to what is below.

• Testing at the Source:  One of the most important distinctions is the emphasis on Agile and Lean techniques of 'quality at the source'.  The intent is to minimize the hand-offs that occur between different groups managing testing and development.  Each team member is responsible for ensuring tests or acceptance criteria exist at each level of the development lifecycle.  Success criteria at the Business Modeling level identify the underlying business model of the system being developed, Requirements written using an Executable Requirements approach have clear pass/fail conditions and can be automated, Unit Tests and a Test Driven Development approach ensure high quality software and the opportunity to refactor the architecture of the system with knowledge of where changes are impacting application functionality. 
• Test Coverage Emphasis:  With the techniques described above the emphasis of individuals in a test capacity becomes focused on testing across user stories or use cases and ensuring business rules and non-functional requirements are adequately tested.  The Test Plan is an important tool in identifying the test strategies that will support the more granular Executable Requirements and Unit Tests mentioned above.
• Incremental and Adapative Testing:  Iterative development testers must be accustomed to testing only what has been delivered within each iteration, and therefore to planning and executing incremental tests of the same – but evolving – functions over time.  Testers should have visibility and engagement in capturing requirements early in the lifecuThey must understand that the absence of a feature in an early iteration not contracted to support that feature is not a defect. They should be able to distinguish clearly between regression testing and planned incremental testing.
• Some more guidance can be found at a short article I wrote in 2002 called Blending A Test Strategy Into an Iterative Development Project

Posted by Bryan Campbell at 01:30 PM | Permalink | TrackBacks (0)

As a project manager for many years I've developed a long litany of techniques and approaches that have helped me manage a wide range of green-field software development, COTS (Custom Off-the-Shelf), and Hardware implementations.  Most of my website is focused on successfully enabling technology to support business value and managing how this happens is covered throughout.  However, here are some brief perspectives that guide a lot of how I view and manage projects.

• Project Management

Project management begins with the emphasis on liveness; that is conferred by agile methods, especially SCRUM and XP.  These techniques emphasize collaboration and 'just enough' structure to meet end-user requirements.  However, these techniques were not intended to replace or ignore the many other aspects that affect projects such as budgeting, resourcing, communication and the remaining elements of the Project Management Institute's Project Management Book of Knowledge. 

I can imagine that many agilists reading this might be recoiling at the thought of the high ceremony, document-centric and waterfall nature that many armed with a PMP certification possess.  From my experience this is more of a reflection of the personalities of the people who have earned these certifications (and granted these personalities tend to gravitate to this area).  One reason I suspect is that as a project manager there is an underlying desire to 'control' the project and its easy to use the PMBOK (and RUP for that matter) to justify this approach.  However, I also firmly believe that effective project managers understand the Agile Manifesto Principle of 'Individals and Interactions over Processes and Tools', these PM's enable their teams so they can control the processes (not abandon them) and that they respect and support their team members to increase their effectiveness.

• Iterative Development

The biggest change that I experienced in managing projects came when I managed my first iterative development project.  The term Iterative Development has many characteristics (some of which you can find in an article I wrote called Hallmarks of Iterative Development) but chief amongst them is their consistent and 'time-boxed' duration (you can learn more about selecting the right iteration length here), rapid feedback, demonstration of business value at the completion of each iteration, and an emphasis on high risk and architecturally significant work first.  I've run iterative projects using small teams, large teams, geographically dispersed teams and with a wide range of techniques (Walls of Wonder, Kanbans, and Commercial software).  All of these shapes and sizes have different benefits and challenges but what I can say is that without using the Iterative development techniques mentioned none of these projects would have been successful.

Posted by Bryan Campbell at 10:54 AM | Permalink | TrackBacks (0)

As many who follow my blog entries and have read my articles know, I use the Unified Process as framework to manage projects and programs.  While the phases of the UP (Inception, Elaboration, Construction and Transition) are powerful ways to manage the risk and narrow the 'cone of uncertainty' of a project, I find the disciplines within the Unified Process as useful containers for ensuring roles are established and that artifacts are being developed that will support the project.

However, beyond the phases and disciplines I find most of the artifacts and activities as too abstract for effective application in most real world projects.  Instead, I mix in a series of techniques that I have applied successfully and found round out the details of each of the disciplines with RUP.

The Requirements Discipline

• Requirements Drive Development:  A Use Case-driven Process

As stated in previous posts and in articles like Real World Development Practices:  RUP and XP , I apply much of Craig Larman's UP style and its emphasis on rightsized, “essential” use cases, which then collectively act as a lynch pin that links together the disparate disciplines of Business Modeling, Requirements, Analysis and Design, Implementation, Test and Project Management.  Furthermore, achieving success with use cases is more difficult than it first appears, and many pitfalls in usage await the inexperienced practitioner.  Consistent application of the techniques espoused by Alistair Cockburn’s de facto standard for specifying use cases and structuring them in relation to goals, which provides a repeatable, traceable discipline for use case development and maintenance.

• Executable Requirements:  Aligning Requirements and Development

These days I particularly like the idea of 'Executable Requirements' (XR) to capture requirements.  This approach has the benefit of not only enabling the Pull method described above but they also ensure that software developed matches the specifications provideds.  XR bsaically provides a mechanism where a requirement is captured in a 'pass/fail' style using an Excel or HTML table to define the requirements.  The power of this approach is that it not only moves requirements out of the fuzzy, prose style that can plague use cases (and which is why use cases have so many sections) but also allow a team to automate a series of tests that demonstrate that a requirement has been 'fulfilled'.  For those of us with a testing
orientation we can immediately see the opportunity to regress through all of our tests every iteration and ensure that new  changes don't break old functionality.  There's a lot to this subject and something that I'll update on more in the future but there are some good reference sources for this such as the Fitnesse wiki and Ward Cunningham's Functional Integration Testing (FIT) Framework.   

• Managing Risk and Non-functional Requirements (ATAM, EVO)

Addressing Non-Functional or Supplementary Specifications is often a neglected component of software development.  Notable references in this area are Tom Gilb’s iterative EVO method, which emphasizes full and careful definition of non-functional requirements (which Gilb calls “attributes” leveraging his Planguage approach) and SEI’s ATAM (Architecture Tradeoff Analysis Method) methodology.  Documentation of all significant architectural decisions – a component of the ATAM approach – as a key mechanism for reasoning about and justifying choices between architectural options.  This fits well with leveraging risk analysis as a major driver of iteration plans.

• Early, Continuous Delivery of Business Value: Complementing the Risk Driver

The agile methods complement UP by providing an important emphasis, not only on risk reduction, but also on the early and continuous delivery of business value.  Hence, a full iterative development discipline has two drivers: delivery of useful functionality and management of risks.  The use case-driven approach, when combined with non-functional drivers and the dispatching of work into developer tasks provides tangible evidence of progress to the business at each iteration’s end.  (See some of the XP,  EVO, and FDD links for further details.)

 The Analysis Discipline

• From Use Cases to Developer Tasks

The Larman method takes analysts and designers through a series of simple intermediate steps leading up to operation contracts on a system or service level interface.  In accordance with Agile Modeling [below], intermediate artifacts need neither be formally developed nor maintained if the ceremony level of the process does not warrant it.  I also believe strongly in a “pull”-driven approach to developer task definition, a key element in Lean Programming [below].

• Applying Analysis Patterns to Streamline Design

I encourage analysts to leverage Martin Fowler’s Analysis Patterns, rather than reinvent the wheel.  This emphasis provides synergy with the product line process mentioned later, and also opens the analysis up to alignment with standardized vertical models such as well defined reference models (e.g. Insurance Application Architecture).  Another useful source of such patterns is Penker and Eriksson’s book.

Posted by Bryan Campbell at 09:29 PM | Permalink | Comments (1) | TrackBacks (0)

One of the early challenges faced by most project managers and sponsors involved in an agile/iterative project is determining how long each iteration should be.  Surprisingly there isn't a lot of guidance that can be used to determine an appropriate iteration length (although Mike Cohn has some good thoughts on the topic) with the result that most iteration cycles are determined without much context on the problem that is being solved.

Here are some quick guidelines I would offer and they're based on some underlying assumptions about an iteration and its characteristics:

Iteration Characteristics

• Time-boxed in length
• Provide a rapid feedback mechanism to encourage business input and validation
• Finish with a demonstration of working software
• Software demonstrates business value
• Software demonstrations are from an end-user perspective and should demonstrate the system using as close an approximation to the end user interface as possible.  In other words, demos shouldn't only show Fitnesse tables or unit tests (they might but be aware that your typical demo audience is more interested in seeing how the system works not its underlying mechanics).

Iteration Length Considerations

• Iterations should rarely be longer than 4 weeks which addresses the second bullet above. 
• Iterations less than 1 week or less have too much overhead associated with preparing for a demo and are too easily impacted by a single team member now being available.

Iteration Length Selection Process

• Pick an iteration length that will allow the team to demonstrate tangible units of business value.  In environments with complex business transaction lifecycles (lots of integrations, actors and business rules) this will take you closer to the 4 week period.
• Select iteration duration around the overall delivery date of the product.  A project which has a 12 month duration, 4 week iterations will provide 12 demo opportunities.  A 3 month project however would only have 3 demos probably not sufficient to get appropriate feedback from business stakeholders.
• Select an iteration length that can be supported by both clients and the development team.  Often times the development team is more than capable of supporting a two week iteration (or even a one week iteration) but without the clients/business sponsors providing requirements on a timely basis the team won't have the right input to provide a demo.  In large companies there are often many stakeholders and consequently the logistics of gathering and validating requirements will take longer, select a 3 or 4 week iteration length in these settings.
• Projects with considerable 'architecturally significant' amounts of functionality of high degrees of novelty typically require longer iteration cycles.  Enhancements to existing system can often leverage the architecture investments that have already been made resulting in shorter iterations.  However, for true 'green field' software development projects a longer iteration length should be selected.

Signs that your iteration length is incorrect:

• Development teams 'miss' demos.  This usually occurs because the teams are pushing development to the last possible moment and introduce a change that breaks the build.  Address this by ensuring a code complete point at least 8 hours before your demo, also label successful builds preferably automatically.  Develop smoke tests that allow you to determine whether build really is successful
• Team velocity shows a 'sine wave' effect.  Low velocity one iteration followed by a spike in velocity in the next iteration.  This usually means the team doesn't have enough time to 'finish' their work and can't take credit for what they've completed.

Changing your iteration length mid-stream through a project isn't something I would generally recommend (you should only do this after you have at least 3 iterations completed and have some of the signals mentioned above), consistent iterations provide a cadence and rhythm to your project and tampering with that will distort your measurement statistics and also disrupt the team.  However, if you give some thought to the purpose of your iteration you should be able to avoid this problem.

Posted by Bryan Campbell at 11:05 AM | Permalink | TrackBacks (0)

With the increasing interest in Agile techniques such as Scrum and XP, I often come across clients and project managers assuming that these approaches alone are sufficient to ensure the success of their projects.  In actuality, the Agile Principles are really a value system that help contribute to effective behaviors on a project.  None of the agile techniques recommend dispensing with the well defined practices that govern effective project implementations such as risk, scope and change management (amongst others).  In fact most of the Agile techniques found in current literature are intended to work within existing frameworks and metamodels, without which your projects won't succeed.

When I develop project plans and teach project management approaches, I frequently turn to the Metamodel offered by the Unified Process.  What I like specifically about the Unified Process is that it breaks a project into four phases (Inception, Elaboration, Construction and Transition) that have clear entry and exit criteria that are easy to manage against.  In addition the phases are well defined and relatively intuitive to most people (Inception involves scoping and structuring the project, Elaboration focuses on de-risking the project and developing an Architecture, Construction emphasizes the rapid development phsae of the project and Transition focuses on readying the application for deployment).

The UP also contains a number of useful 'disciplines' which reflect major workstreams in a project lifecycle.  Business Modeling, Requirements, Analysis and Design, Implementation, Test and Deployment ebb and flow across the project lifecycle while Project Management, Configuration/Change Management and the Environment disciplines are focused on supporting the lifecycle in its entirety (these latter are found in the IBM version of the Unified Process called the Rational Unified Process.

The popularity of the Unified Process is reflected in its evolution into a number of forms including the Agile Unified Process, Enterprise Unified Process and even the Oracle Unified Process.  IBM recently released an open source version called OpenUP which is based on its popular Eclipse Process Framework.

Over time I've come across a number of agile/lean techniques that support the disciplines I mentioned above and enhance these disciplines to make them more effective.  Over the next few postings I'll offer a walk through on a discipline by discipline basis on each of these techniques.

Posted by Bryan Campbell at 11:07 PM | Permalink | Comments (1) | TrackBacks (0)

One of the challenges of effectively implementing a large scale, enterprise iterative development program is that there is little in the way of literature on how to effectively scale iterative projects into a program.  Most of the literature focuses on the 'relatively' well defined issue of managing a single software development project.  Looking at Scrum, XP, DSDM and even RUP none of these approaches really address the challenges of implementing iterative development techniques across a broad number of software development projects that operate as part of a program. 

While there is a good program management plug-in for RUP and Ambler's Enterprise Unified Process extends RUP beyond its project phases, there is nothing readily available that provides a lightweight and highly engaged program management office which applies some of the same principles of iterative development to a Program Office.  Of course there is a well established body of knowledge around Program or Programme Management but these bodies of knowledge emphasize a program office focused more on administrative and financial oversight of a number of projects.   

Large enterprise deployments to tens of thousands of users have 'long tails'.  These tails represent the time and effort that goes into deploying an application into multiple separate environments for testing, training and ultimately transitioning into Production.  RUP uses the Transition phsae to capture some of these activities but most large organizations have their own specific processes including 'black-out' periods, SOX and other compliance needs and the need to coordinates across multiple departments.  Where many large organizations struggle with adopting iterative development processes is when they begin to examine the practicality of moving a release through the long tail of their deployment process.  Since this tail often has an insatiable desire for detailed requirements (to justify purchasing expensive hardware or to satisfy Service Level Agreements with outsourced support organizations) it becomes enticing for the organization to move back to its waterfall approach (or it redefined iterative development as simply applying to the RUP Construction phase). 

Tackling this challenge requires a thorough understanding of the organizational dynamics of large scale organizations and a willingness to educate the often independent groups which support the 'tail' of the deployment process.  The first step is to adopt a more program centric view of how multiple projects can work together leveraging an approach such as the System of Systems pattern. The next is to develop a communication and awareness plan which helps support groups in the 'tail' better understand how iterative development practices work and what they can do to support this approach.   I'll try and write up some specific observations of how to tackle these program level iterative development issues in the weeks ahead.

Posted by Bryan Campbell at 02:47 PM | Permalink | TrackBacks (0)

I came across some interesting material from Rally Software Development recently which closely aligns with what I consider the most important elements of effective software development techniques.  One of the things I particularly liked about the whitepaper Rally has published (Tactical Management of Agile Development: Achieving Competitive Advantage) is that it provides more visibility into the somewhat nebulous concepts of "Release Planning".  

In their paper, Leffingwell and Muirhead, describe Release Planning as the exercise which occurs at the start of a project where product owners, the development and customers (or their proxies) agree on the set of scoping and scheduling activities around which each iteration should occur.  They identify a lightweight process where they have abstracted several high level workflows, specifically "Define Release Objectives", "Scope Release" and "Schedule Release".  This creates a Release Roadmap which they emphasize is a coarse grained release plan which is neither comprehensive nor guaranteed.  This exercise could be a 2-3 week effort based on the size of the project which sits well with how I would advise an organization embracing a larger program initiative.  

They also distinguish between "Schedule Driven" or "Scope Driven" projects.  The former is defined as having a specific date which is required for implementation and based on this scope is adjusted based on the team's commitment to deliver and velocity observed over progressive iterations.  Scope Driven identifies a list of prioritized backlog items from which a schedule is derived.  The thing I like specifically about focusing on two general approaches is that there is considerable value in picking a specific metaphor at the start of the program and moving forward with that goal in mind.  

Too often I have seen organizations attempt both approaches although typically this is difficult to see initially.  It typically occurs when there are two or three groups with equal decision making capacity in the program.  You know this is happening when you hear a group of key stakeholders agree that they want to apply a schedule driven approach but you hear one of the stakeholders add something to the effect of "After we define a solid architecture" or "Once we have a good handle on the business requirements".  These statements are so nebulous and open to such wide interpretation they essentially prevent a Schedule driven approach from being applied.  The architects will head off and debate Hibernate versus OJB for several weeks, the business representatives will disappear and hold lengthy all day meetings trying to agree on what business processes are currently being performed.  Both of these activities might have value but they shouldn't cloak the fact that the project should be more scope driven (which by the way might include architecture validating activities not just business value activities). 

Posted by Bryan Campbell at 02:16 PM | Permalink | TrackBacks (0)