When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:
- The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile. To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.” As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans! Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile. Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
- The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques. Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools. I call them tools because the analogy with construction tools is a very good one. Scrum is like a hammer. But you can’t do much with just a hammer. Scrum is a great, simple tool. But you always need other tools as well to actually get stuff done. All the tools in the Agile Toolkit are compatible with the Agile Values and Principles. Even so, it is possible to use the Agile Tools without being Agile. A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” (Video conferencing doesn’t count.)
- The Agile Organization – When you start using a tool, there is a learning period. We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet. Eventually, with continued use, we become unconscious of the tool. IDE’s and version control are like this in most organizations: we don’t even think about them! But getting through that initial stage requires us to change; to develop new skills. This process usually requires discomfort or pain (including psychological pain). An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult. For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc. All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT. These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic. This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.
All of this is summarized in this graphic:
The Agile Framework [PDF]
I sometimes also call this the “Agile Ecosystem” since it is a constantly evolving set of ideas (processes, tools, resources) that does not have a clearly defined boundary. For example, the technique of Value Stream Mapping comes from Lean manufacturing but has also be broadly adopted by Agile practitioners.
Myself, Paul Heidema and a few other people we work with have now participated in several assessments of organizations who are either looking at adopting agile methods or improving existing use of agile methods. We have developed several tools for running these assessments. The following things are critical to the assessment process and the results we get:
The success of an agile transformation is primarily driven by connection that transformation makes with the existing culture of the organization. We know that doing an agile transformation includes cultural changes. The critical piece is understanding the culture so that you can determine what in the culture supports agility and what in the culture is going to hinder agility. A culture that focuses on individual accomplishment and freedom will not support agility well, while a culture that supports doing the best possible thing for customers will support agility. Of course, any given organization will have a mix of cultural aspects that both support and hinder agility. There are a number of methods for examining culture including an excellent corporate culture workshop described in the book “The Corporate Culture Survival Guide” by Edgar Schein.
Value Stream Mapping
A high level value stream map is an excellent tool for identifying both an overall need for improvement by making the current state of affairs visible, as well as pinpointing where big improvements can be made quickly. More often than not, when we do an assessment for an organization, we are finding that the efficiency of their process is at about 20-30%… in other words, 70-80% of all effort is expended on wasteful activities. This level of waste is often surprising for stakeholders. And of course, making that level of waste visible is a large motivator for the kind of continuous improvement that agile methods such as OpenAgile and Scrum make possible.
Of course, even if an organization is not doing agile officially, there are often existing practices that can be considered part of the overall umbrella of agile. A comprehensive assessment that rates a team’s or an organization’s level of use of agile practices gives a good picture at a very practical level of what things you can build upon. For change to be successful, a significant factor is to tie new practices to existing practices. This is a great way to do this. There are lots of lists available of agile practices. We publish one fairly comprehensive list of agile practices on the Berteig Consulting site (it’s near the bottom of the linked page).
There are of course many other things that are done during an assessment, but these three form an effective foundation for any agile transformation plan.
Isráfíl Consulting is finally prepared for the first series of its Agile Software Engineering Practices training courses. This series is offered in partnership with Berteig Consulting who are graciously hosting the registration process. Their team has also helped greatly in shaping the presentation style and structure of the course. The initial run will be in Ottawa, Toronto (Markham), and Kitchener/Waterloo.
Topics covered will include Test Driven Development (TDD), testability, supportive infrastructure such as build and continuous integration, team metrics, incremental design and evolutionary architecture, dependency injection, and so much more. (This course won’t present the planning side of XP, but covers many other aspects common to XP projects) It makes a great complement for training in Agile Processes such as XP, Scrum, or OpenAgile. The overview slide presentation is available for free download from the Isráfíl web site.
The courses are scheduled for:
The course is $1250 CAD per student, and participants receive a transferrable discount of $100 CAD for other training with Berteig Consulting as a part of our ongoing partnership. I initially prototyped this course in Ottawa this December, and am very excited to see this through in several locales. Class size is limited to 15, so we can keep the instruction style more involved. The above schedules are linked to Berteig Consulting’s course system and have registration links at the bottom of the description. Locations are TBD, but will be updated at the above links as soon as they’re finalized.
A further series is planned for several US cities in March, and we’ll be sure to announce them as well.
This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices. Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt). I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses – if you want it in MS Office format, email me at firstname.lastname@example.org). I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”. I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development. I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve. Perhaps it could be used in a retrospective setting. Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients. If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments. My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.
Agile Practices Adoption Worksheet (OpenOffice format – 68KB)