I am trying out Microsoft Live Writer for my blog posts this week.  This is part of the new Windows Live offering. This integration of desktop applications in the cloud combined with the impact of mobile computing and massive search capabilities is going to fundamentally change the way we think about software over the next few years.

So far, I think its going to work out fine. It is easier than writing in Word and then pasting into Wordpress. I have the opportunity to store a draft locally, store it in the cloud, publish it as a draft to my blog. I had some interesting challenges with formatting in my recent BABOK® series. Let’s see if the formatting, spell checking, and ease of editing makes this a good tool to use.

So far I am happy with it. I only have two challenges up front. I write most of my blog posts over the week end and then schedule them for the week. While this let’s me set a publish date it doesn’t let me set a publish time. The second challenge is that it didn’t take me to right preview. I am going to try it for a week or two and see if I like it.

This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

There is a lot of interesting conversation going on within the project management, product management, and agile software development communities. There is contention between (and within) the different communities regarding the value and benefit from the other domains. Sometimes one community is vying to prove their domain is superior to the others. Other times, a community is casting blame for limitations in their ability to perform to another domain. Much of the conversation is based on a limited understanding of what the other domains actually do. They also fall into the trap of generalizing a specific unpleasant experience to encompass the intent of the other community.

I believe this debate is counterproductive. At the end of the day, everyone’s interest should be to improve their organization’s ability to profitably create value for the customer. Each of these areas has something critical to contribute to this goal – but the benefits are only realized when the communities work together. I want to define a few terms, identify the overlap, and then suggest why this discussion is not just an academic exercise, but it an important part of the maturing of each domain.

First, some definitions:

Project Management

Let’s start with Project Management. The Project Management Institute has the following definitions of project, project management and project manager.

Project: A temporary endeavor undertaken to create a uique product, service or result.

Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

Project Manager: Person assigned by the performing organization to achieve the project objectives.

Project Management is not meant to be an obstacle to getting work done. In fact, the project manager is responsible for ensuring the project is successful.

Product Management

The Product Development and Management Association define product, product management and product manager.

Product: A term used to describe all goods, services, and knowledge sold. Products are bundles of attributes (features, functions, benefits, and uses) and can be either tangible, as in the case of physical goods, or intangible, as in the case of those associated with service benefits, or can be a combination of the two.

Product Management: Ensuring over time that a product or service profitably meets the needs of customers by continually monitoring and modifying the elements of the marketing mix, including: the product and its features, the communications strategy, distribution channels and price.

Product Manager: The person assigned responsibility for overseeing all of the various activities that concern a particular product.

So the Product has an ongoing aspect to it that the Project doesn’t. The Product Manager decides what needs to be built and also how the organization will sell it and support it.

A product has a life that lasts beyond any individual project.  The ongoing thing over at PMI is called a Program. Here is the PMI definition for Program and Program Management. Interestingly, PMI doesn’t define Program Manager in the Program Management standard.

Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually, Programs may include elements of related work outside of the scope of the discrete projects in the program.

Program Management: The centralized coordinated management of a program to achieve the program’s strategic objectives.

Project Management Isn’t Product Management

So project management isn’t product management. Neither is Program Management, However, there are projects to execute in the modifying of the product, so project management processes matter in product management.  Here is a Venn diagram that describes the relationship.

If you aren’t good at making changes to your product or the capabilities in your organization that relate to your product, you won’t be a successful company. So project management isn’t product management, but there is overlap in practices and both are important to your organization. Great ideas with no execution aren’t valuable.

Agile Software Development

Finally, let’s go with the Agile Manifesto as a definition of Agile.

Manifest for Agile Software Development

• Individual and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Despite the perspective of many in the project management and product management communities, Agile is also not intended to be no planning, no documentation, irresponsible software development. According to http://agilemanifesto.org/history.html :

 “The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

Agile is not Product Management

Agile is specifically about software development. In fact, the Agile Manifesto is short for the proper title of Manifesto for Agile Software Development. Agile is an approach to software development that includes practices and principles that can result in dramatically faster and higher quality (therefore less expensive) development of software. But the product is not just software. If the right features, communications strategy, distribution channels and price are established being faster, cheaper, and better at software development doesn’t matter. Product Management is critical to getting value from Agile Software Development.

Agile is not Project Management

 In very few cases is the product that is being sold to an organization’s customers just software. We’ve discussed the relationship of Project and Product Management above.  You need to be good at Project Managing all aspects of change to the product and the capabilities in the organization that support and are affected in any way by the sale, delivery, billing, and support of the product to the customer. Also, Agile isn’t concerned with Procurement – but procurement is important to the profitability of the company. And while iterations are a Risk Mitigation tool, Agile does not have a specific Risk Mitigation aspect to it.

Why this discussion matters

The following Venn diagram depicts the interdependency between these three domains.  Value is not delivered by any one of these domains. It is through an effective coordination between these domains that value is delivered to the customer. Value is identified, shaped, and then communicated to the customer by Product Management. Much value is created by the Agile development team itself. Value is created through aligning the other capabilities within the organization and often actually delivering the product to the customer through Project Management.

Let me quote Jim Highsmith from http://agilemanifesto.org/history.html again.

“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. “

Most of the organization’s that I have been involved with that are failing to deliver software to the business or the business’ customers are failing to receive value because of deficiencies in one or all of the domains in this discussion. Often, the deficiencies are the result of conflict and lack of coordination with another domain. Becoming great at one area, while remaining poor in another, is not value to the customer, the business, or ultimately to the members of the organization. 

The discussion we need to be having is not about how each domain contributes to problems for the other domain.  This is an interdependent problem, not one that has its roots in any one domain. Bunkering down, defending incompatible practices, focusing on local optimization at the expense of the business is not going to work. We need to work together to answer this question. How do we align the product management and project management practices with the rapid, incremental delivery of working software to optimize benefits for our customers and profitability for our businesses?

I come from a big project, high ceromony background. I learned Software Engineering as contractor at IBM in the 80’s, was a Marine, and believe in the PMBoK (Deputy PM on OPM3® Second Edition). Over the last 10 years I have studied and learned Agile from books and through mentoring relationships. I have applied what I understood and have experienced improved performance. But I still thought of Agile/Scrum as a less than responsible way to do work.  I have heard a lot of push back on Agile and Scrum in blogs and on Twitter lately. “Scrum doesn’t work”, they are saying. “Scrum makes the devleopers life easier but hurts the customer”, is another one. “The lack of overall budget/timeline is a killer (only look 1 sprint forward, really)”, is a charge hurled this week. 

Last week, I went to the source and completed Jeff Sutherland’s Certified Scrum Master course. During the training with Jeff Sutherland last week, he presented a ScrumBut test. We are doing Scrum but… means you aren’t doing Scrum. Not doing Scrum means you likely won’t get the benefits other teams that are doing Scrum have claimed. Scrum, when done well, is a responsible way to develop software and if positioned maturly is a benefit to management. With permission from Jeff, here is the ScrumBut test. Take the test, add up your scores and divide the result by 9. 

Question 1 – Iterations

- No Iterations – 0
- Iterations > 6 weeks – 1
- Variable Length < 6 weeks – 2
- Fixed iteration length 6 weeks – 3
- Fixed iteration length 5 weeks – 4
- Fixed iteration length 4 weeks or less – 10

Question 2 – Testing within the Sprint

- No dedicated QA – 0
- Unit tested – 1
- Feature tested – 5
- Feature tested as soon as completed – 7 
- Software passes acceptance testing – 8
- Software is deployed – 10

Question 3 – Agile Specification

-No requirements – 0
- Big requirements documents – 1
- Poor user stories – 4
- Good requirements – 5
- Good user stories – 7
- Just enough, just in time specifications – 8
- Good user stories tied to specification as needed – 10

Question 4 – Product Owner

- No Product Owner – 0
- Product Owner who doesn’t understand Scrum – 1
- Product Owner who disrupts team – 2
- Product Owner not involved in team – 2
- Product Owner with clear product backlog estimated by team before Sprint Planning meeting (READY) – 5
- Product Owner with a release roadmap with data based on team velocity – 8
- Product Owner who motivates the team – 10

Question 5 – Product Backlog

- No Product Backlog – 0
- Multiple Product Backlogs – 1
- Single Product Backlog – 3
- Product Backlog clearly specified and prioritized by ROI (business value) before Sprint Planning (READY) – 5
- Product Owner has release plan based on Produce Backlog – 7
- Product Owner can measure ROI (business value) based on real revenue, cost per story point, or other metrics – 10

Question 6 – Estimates

- Product Backlog not estimated – 0
- Estimates not produced by team – 1
- Estimates not produced by planning poker – 5
- Estimates produced by planning poker by team – 8
- Estimate error < 10% – 10

Question 7 – Burndown Chart

- No burndown chart – 0
- Burndown chart no updated by team – 1
- Burndown chart in hours/days not accounting for work in progress (partial tasks burn down) – 2
- Burndown chart only burns down when task is done (TrackDone pattern) – 4
- Burndown only burns down when story is done – 5
- Add 3 points of team knows velocity
- Add two points if Product Owner release plan based on known velocity

 Question 8 – Team Disruption

- Manager or Project Leader disrupts team – 0
- Product Owner disrupts team – 1
- Managers, Project Leaders or Team Leaders telling people what to do – 3
- Have Project Leader and Scrum roles – 5
- No one disrupting team, only Scrum roles – 10

Question 9 – Team

- Tasks assigned to individual during Sprint Planning – 0
- Team members do not have any overlap in their area of expertise – 0
- No emergent leadership – one or more team members designated as a directive authority – 1
- Team does not have the necessary competency – 2
- Team commits collectively to Sprint goal and backlog – 7
- Team members collectively fight impediments during the sprint – 9
- Team is in hyperproductive state – 10 

My best recent project scored a 6.7 on this test and we didn’t call it Scrum – we just considered it responsible management of an analytics projecyt. We did perform really well in a tough situation though. If you score less than a 6 on average, you probably aren’t doing Scrum. That may be good or bad – but if you aren’t doing Scrum, don’t call it Scrum. If you aren’t performing at a hyperproductive level, look at the areas where you didn’t score as well. It is likely they will highlight the next most important impediment for you to focus on removing. Fix that and move forward.

If you aren’t familiar with the story of The Blind Men and The Elephant it is about six blind men that go to study an elephant. When they come back, they all report on the elephant in different ways. They variously report they found a wall, a spear, a snake, a tree, a fan, and a length of rope. They argue to defend their perspective. The discrepancy lies in the fact that each studied a different part of the elephant. The poem and the related illustrations at the link above demonstrate the story very well. The story is a metaphor about how we see the world from our individual perspective and have a difficult time understanding the bigger picture.

Delivering software and technology is a lot like that elephant. Over my career, I have been the blind man trying to figure that elephant out. I wrote code for the first decade, then began to study what great code and then architecture looked like. I joined user groups and associations and studied the engineering practices around software development. I studied function point counting and became a member of IFPUG. In the mid 1990’s Senge and Ackoff seeded my Systems Thinking perspective. My work at Perot Systems shaped my Business Process Re-engineering perspective. My degree is in Organizational Psychology and Development and I have been fascinated with the role language, knowledge creation, and team dynamics play in this area. I first read “The Goal” and “Critical Chain” in 1998 and have studied and applied the TOC thinking processes and CCPM to project scheduling. I have been greatly influenced by Theory of Constraints thinking. I have been around Agile development for over 10 years. I have a bookshelf full of eXtreme Programming and Agile books. I am also very involved with the project management institute as well, earning my PMP in 1998 and I spent the last couple years as the Deputy Project Manager of the Organizational Project Management Maturity Model - OPM3®.   I earned my Lean Value Stream Mapping certification from the Lean Enterprise Institute in 1999.

In each of these cases I went into the community trying to learn what they had to offer and figuring out how to responsibly help companies profitably deliver technology. One of the interesting things I have consistently observed is the disdain these communities hold for most of the other communities.  I was at an Architecture conference in 1991 where the various OOAD people were actually yelling about the best way to identify objects for a system. The TOC and Agile people really dislike the PMI people. Even inside the Agile community, the Lean and Agile groups are at each other’s throats. Engineers discount the human elements and the softer side of team dynamics.  Everyone is arguing for the importance of their view of the elephant. High ceromony scoff at the lack of maturity of the low ceromony while the low ceromony ridicule the waste of heavy and useless process and artifacts.

The problem is that the answer is not one particular part of the elephant. No one is completely right. We need to optimize the entire elephant and turn it into a sleek and agile race-horse. The battles between whether the elephant is a tree or a fan or a snake are not productive. They obscure the path to improving the ways that we can responsibly and profitably deliver value to our customers.

I spent last week at a course with Jeff Sutherland, one of the creators of SCRUM. The SCRUM he talks about is different than what I have seen on many SCRUM teams or read in books. Jeff incorporates aspects from Theory of Constraints, and Lean, and Knowledge Management. He promotes the items in the Agile Manifesto but incorporates elements from everything he has learned and observed. Jeff is trying to build a “big-tent” approach that brings responsible practices together while increasing performance and developing hyper-productive teams.

I encourage each of us to recognize our myopia in understanding this elephant. Try to understand the basic principles behind each practice and idea. Let’s agree that the way organization’s identify, manage, create, and deliver technology to organizations and customers is insufficient and put a lot more energy into improving. Technology plays a very important role in our economy today. We can’t get good enough fast enough right now, and dogmatic wars are too costly. What can we be doing to rapidly cross-pollinate and greatly improve our ability to profitably deliver value to our customers?

Here is an SOA Definition from the SOA Working Group of the Open Group.

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

·         Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)

·         Is self-contained

·         May be composed of other services

·         Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed.

The SOA architectural style has the following distinctive features:

·         It is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.

·         Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.

·         It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.

·         Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.

·         It requires strong governance of service representation and implementation.

·         It requires a “Litmus Test”, which determines a “good service”.

There are some really important distinctions about the SOA definition.

SOA is not technology – it is a way of thinking about architecture. There are various standards around services that lead to interoperability, but these standards are technical standards – they are not SOA.

SOA discussions are about business outcomes – not about technology. One really important thing is to identify and deliver services that provide business value. We don’t need to be discussing SOA with the business – they just don’t care (hence its demise). We need to get architects thinking about the business, and what the business does to create value for the customer. Then that can be translated that into a technology solution.

I believe that a business capability-based assessment of the company is a great way to facilitate this discussion between technology and the business. A business capability is a something the business does which produces a specific result or outcome. A business model can be viewed as a network of business capabilities. When viewed this way, you can identify those capabilities that need to be changed or improved to accomplish the business strategy. From these capabilities, you can identify services that are valueable to the business. Now you are having a business discussion that aligns your business model to the technology.  And you can align your technology investments with the best interest of the business.

You can get a copy of “The Next Revolution in Productivity” to look at an approach for doing this. Either go to the Harvard Business Review website and buy one, or get one for free by registering at http://www.synaptus.com. (Official Disclosure: I was an author on the paper). I also have a tool set I will share with individuals who want to help improve this approach.

I will be writing more about business capability analysis as a way of identifying where to focus improvements in the business, and how to identify where SOA is a good approach. I would appreciate feedback on the article and the capability analysis approach.