3months Agile Consulting Blog

I did not intend to write an article specific about retrospectives as part of this series - however I couldn’t help it after today’s experience. I haven’t been to a yoga class in ages and was surprised when at least two thirds of the attendants left the minute the last posture was finished.

Integrate what you have just done

Traditionally the last pose however is Savasana - the final relaxation. Its purpose is to integrate and assimilate what was just practiced - both on a conscious and unconscious level. It is up to the practitioner how long he/she will stay in this pose - usually between 5-15 minutes. Today’s experience makes me think that the benefits of these pauses to reflect and assimilate are apparently not well understood - and hence considered to be nonessential.

The same is potentially true to retrospectives - the Savasana of an agile project. Common reservations include “No time for that” or “It costs too much (all team members are tied up for 1-2 hours)” - totally neglecting the benefits of continuous process improvement and the potential to deal with conflict before it becomes a blowup. After all, if you knew at the beginning of the week what you know now, how much time could you have saved? Why would you not want to learn from this past experience and save the time this week?

So I encourage you to integrate retrospectives in your iterations and at the end of projects! The structure of a retrospective is pretty much open. Don’t shy away from addressing emotional issues in them as well - particularly during projects. Bring out reservations, enthusiasm, resentments - find out what is close to the heart of the team. Only then you can deal with it!

The Agile Yoga

1. The Agile Yoga
2. The Agile Drushti
3. Intermezzo - The art of retrospectives
4. The Agile Asana
5. The Agile Vinyasa (coming soon)
6. The Agile Bandhas (coming soon)
7. The Agile Pranayama (coming soon)

Now that the impressions from the barcamp e-government un-conference had a chance to settle in a bit it is time to look at some of the lessons learned.

First and foremost I saw the stunning results achieved if reverting from a command-control pattern to giving up control. Traditional projects are typically managed with tight control constraints. The project manager often has the feeling he/she must maintain control over the development process - even though it usually is not his/her core competency at all.

Most agile software development methodologies (particularly Scrum) hand over control of the development to the team and the customer. The project manager becomes more of a facilitator and administrator. That’s not to degrade him/her - on the contrary his/her relationship skills are very valuable to the team as he/she removes obstacles in the way of the team.

By giving up control of the session content and structure the organizers allowed the audience to steer the conference towards maximum value. There were some core themes but whenever something else (related or not) was closer to the heart of the attendants then it was addressed. Very much like an evolving “product”!

Another related lesson is probably that the initial organisation should be kept to a minimum and restricted to finding a venue and sponsors and getting the word out. Don’t worry too much about a structure or speakers as all that will change (anybody seeing familiarities with software projects?).

Drushti is associated with the element of space and as far as the practice of yoga is concerned, space represents freedom: the ability to act at will in any manner and direction. Drushti is directed attention, in which the energy of awareness is focused on a specific object, process, situation or phenomenon. It is the focus on the quality of awareness.

Keep your focus and be aware!

The Agile Drushti emphasizes the focus on mission, strategy and business value. Keep your organization’s purpose in mind - see the big picture! Be aware of what your organization (no matter if corporate, government or non-profit) is trying to achieve! One way to address this could be by putting up signs or charts on your premises - reminding everyone of the common goals. If your organization is too big try the same within your business unit or government department. Another way are company briefings or newsletters in which the organization reinforces the message and keeps staff up to date with progress in strategy and ongoing initiatives. In short do whatever is necessary to ensure that every project, every initiative contributes towards the goals.

Once you decided to embark on a particular project be focused - be committed! Direct your attention to it and make sure that all stakeholders and interested parties are aware of it. Make an effort to identify and engage critical and essential stakeholders (critical being stakeholders who potentially can stop a project, essential being the ones that can delay it)!

In yoga the practice is not about quantity - it’s about quality. If you can’t keep the focus for more than 10 minutes - then do it for 10 minutes only. Over time you will inevitably improve. Challenge yourself but don’t strain yourself! The same is true for your organization. Keep your focus! Take on only as much as you can to still be able to fully commit yourself to it!

The Agile Yoga

1. The Agile Yoga
2. The Agile Drushti
3. Intermezzo - The art of retrospectives
4. The Agile Asana
5. The Agile Vinyasa (coming soon)
6. The Agile Bandhas (coming soon)
7. The Agile Pranayama (coming soon)

There’s a first time for everything - and for me today it was my first unconference (a term so new that even my spell checker complains ). I stopped by the Fronde hosted barcamp session around e-government and was pleasantly surprised. Around 100 people turned up to talk about all aspects of topics around e-government - from policy to projects and software development to identity and privacy.

But while some of the content was quite interesting it really was the concept that fascinates me. An open invitation to the community to participate without dedicated speakers, topics or timelines. In an agile tradition a big flip chart was attached on the wall in the reception with sticky notes with sessions. Anybody could put up a session on any topic at an available slot. All sessions were well attended and not necessarily about the original topic - the community was driving the content - how agile is that?!? I am thrilled to be able to talk about Agile in Government in such a setting
As for the content the highlight for me was the discussion about Identity/Authentication (and the separation of the two aspects) and related topics like privacy, transparency etc. This is becoming more and more important and is not a technology issue at all. There is quite a philosophical aspect to it as in how far do we want to go with that. And the answer is that this is not a government decision - this is about what we as a society decide!

So well done Mike for organizing this and props to everyone involved to make this work!

In the Western society the practice of yoga has become more and more a synonym for agility. As a non-practitioner one is inclined to believe that yoga is just a fancy name for stretching - creating agility through bending in all directions. As a practitioner you learn quickly that your body will only take you as far as your mind is willing or able to. Yoga challenges your body and mind.

Open your mind and the body will follow

The same is true for adopting agile in your organization. Don’t make the mistake thinking that implementing some of the so-called agile practices will make your organization agile overnight. Just like in yoga you will have to fight against limitations and blockages if you concentrate your efforts purely on physical aspects - or in this case on practices and processes. Yes, you will see some progress initially but you will soon hit a wall and progress will become stagnant.

This series is an attempt to apply ancient knowledge (after all the yoga tradition is more than 2,000 years old) to a question close to the heart of many people and organizations right now - the ones that have recognized that they have to become more agile - more adaptive - to the ever-changing marketplace: Just how do we do that?

In the tradition of yoga teachings I will focus on the five techniques expressing the five elements Space, Earth, Water, Fire and Air - Drushti, Asana, Vinyasa, Bandhas and Pranayama. In yoga these five techniques are considered to be facets of a single diamond - while they are five from the outside they are one from the inside. Together they create an energetic model of the full potential of life. Each one is equally important and supportive of the others - therefore improvements in one area will immediately impact the others and open up room for growth in these areas.

So without further ado let me take you on a journey to agile enlightenment

The Agile Yoga

1. The Agile Yoga
2. The Agile Drushti
3. Intermezzo - The art of retrospectives
4. The Agile Asana
5. The Agile Vinyasa (coming soon)
6. The Agile Bandhas (coming soon)
7. The Agile Pranayama (coming soon)

The Software-as-a-Service (SaaS) business model is taking the world by storm with its promise of no-hassle On-Demand service subscription (typically for a monthly fee). More and more packaged-software vendors are at least contemplating a SaaS version of their product offering. But don’t be fooled! SaaS solutions live in a totally different context than more traditional desktop products! Web 2.0, Product Development 2.0, Mashups and the likes are ruling this world now. Product release cycles of 6 months or longer are just not acceptable anymore.

Being involved both in smartbeanz (a financial management SaaS solution) and in product development at Fronde I take a strong interest in the dynamics around SaaS. While my CEO Jim has some insight on SaaS strategies for packaged software vendors (read also Sinclair Schuller’s post) Troy Wing (CTO of Forcelogix) names Agile Development Methodologies as the number one factor for a successful adoption of a SaaS business model. I quote:

Software as a Service Development is all about low cost, high quality and speed of delivery.
You cannot afford to adopt a bloated and slow approach to delivering features.
Users will identify features and issues that will become showstoppers unless you can resolve quickly.
The ability to deliver new features quickly will also help retain user interest in your product.

I couldn’t agree more! For smartbeanz we have a monthly release cycle working off the highest priorities on the product backlog. Yes, we have a road map but user feedback and a ever-changing market place frequently forces us to re-prioritize or even add and implement new features which originally weren’t on the road map at all. At Fronde we are currently designing a product where we didn’t know what exactly it would look like when we started - yet we are very happy with were we got to now! None of this would be possible without an agile mindset, agile development techniques and short time-boxed iterations.

And if you’re still in doubt about the merits of agile development in a SaaS world read what Salesforce.com (the prime example of SaaS success) attributes its success to (download the report as PDF).

It came up in recent presentations I did around our engagement model and Agile Project Management offering: “How can one win a fixed-price fixed-scope fixed-time RFP?”

Ayende just posted an excellent article about this scenario, the common responses from agile speakers, his thoughts and a sensible approach to it. I quote:

Well, you need to estimate the work from the RFP as you would usually do, and submit a proposal based on that estimate. It is likely that you will have a higher proposal than the low-balling guys, and if the only thing on the table was money, that would be a problem. The key as far as I see it is to find, not the bean counter that is signing the check, and usually couldn’t care less about the project itself, but the real customer, the one that wants the actual work done.

If you can get there, you can explain why your proposal is higher (quality, no back stabbing), why you would end up with a better result (early deliverables, immediate feedback, etc) and how it directly benefits the customer to go with this approach.

I believe this is leading in the right direction. There is no silver bullet and it always comes down to judgment calls, experience and context. There are however common themes in these RFPs:

• There are typically low-balling bidders involved employing less talented people (to make profit on margins) and change-control the living hell out of the client once the project is won
• The client is inexperienced in software development projects or has no real interest in the project deliverables (e.g. legislative requirement)

What hasn’t been mentioned yet is the fact that you as the vendor typically have a chance to ask questions and/or meet the prospective client face-to-face. That is your chance to get a feeling for a client’s motivation. If you get the feeling that there is no strong interest to make this project successful or no movement in terms of scope then my advice would be to stay away. Why would you engage in a project when there is little chance of success or the client just wants to screw you. If you are an agile organization chances are it won’t be aligned with your principles and values.

If you chose to pursue the RFP then you want to address not only the typical arguments for agile software development but also the cost transparency and value proposition. Point out that the cheapest response is not necessarily the response with the least costs for the project. Talk with them about the maintenance costs after go-live as well and that they proportionally increase when accepting a low-quality output (which is fine as long as it is a conscious decision).

Agile works because it is based on openness and trust. Agile works because it is based on common sense. Having a conversation with a client about the whole-of-life model of a project (including development and ongoing operational costs) can be powerful and create a sense of trust.

You typically can’t win a fixed-price fixed-scope fixed-time RFP on price unless you manage to include the hidden costs of non-agile vendors into the equation!

Embarking in a new project for an organization that isn’t known for its agility but rather for political agendas - yet still being asked to deliver within an aggressive time frame - I am forced to think about how we can successfully implement an agile mindset and increase our chances of success.

This is not so much about implementing agile software development techniques - we have full control over whatever techniques/tools/processes we want to use. This is more about how we can effectively engage our client to participate and if not become a more agile organization at least create a collaborative and trusting environment.

Christopher Avery summed up some findings and opinions of executives from his think tank session at the Agile 2007 conference. Not surprisingly the consensus about risk is around:

• An agile front line — i.e., development teams — with a traditional management approach (read “silo” mentality and culture) over them is not sustainable.
• An agile development environment deserves and requires a collaborative executive leadership that treats change as easily as does the front line.

He then pointed out that “… for agile development practices truly to be adopted, executive teams must become more agile as well” (meaning to adopt pairing, daily stand-up meetings, retrospectives etc). I like the idea - A LOT! I can only suggest you go ahead and read his entire post.

Coming back to my original concern however as an (external) IT service provider it is unlikely that we can change the culture in the short term. So what can we do? Well, for starters we can identify all critical stakeholders and get them in a room (in Agile Project Management we call this a RAP session) to

• Define success: What are the criteria to consider the project a success?
• Define scope: What’s in scope? What’s out of scope but related? Who is responsible for out-of-scope items to happen?
• Identify stakeholders: Who has interest? Who is impacted? Who can stop or delay the project? (If you don’t have all of the latter in the room consider running another RAP with them)
• Define quality: What does quality mean for this project? What is good enough?
• Identify risk: What are the risks?

This session will expose misunderstandings and differences in expectations between stakeholders. It will also help establishing a trusting and open relationship. With that in place we are already half-way there.

We can then proceed to create a collaborative environment. Start by siting next to each other or facing each other (by all means avoid sitting with your back to each other). Have an environment set up and ready to demonstrate the solution to interesting parties. Have regular presentations (e.g. end-of-iteration presentations) to keep the business involved and interested (not to mention the shortened feedback cycle).  Invite stakeholders to your daily stand-up as observers and give them visibility of progress (be it access to a portal or point them to a whiteboard with sticky notes on it).

Over time people will pick up what works well and find out how they can bring it to their tasks!

If you are an executive and it is your own organization Mike has some suggestions how to create a more productive and open environment.

After ranting on and on about focusing too much on basics and development techniques in agile discussions I guess it’s time to be more constructive. I have mentioned business alignment and added business value before so let’s dive into that for a moment.

For the purpose of this discussion I will stay away from agile software development and rather call it iterative development - emphasizing the focus on short time-boxed development cycles at the end of which a vertical slice of fully-tested and production-ready software is delivered. The value proposition here is manifold:

• Early exposure of a working piece of software to the business will make the software so much better - there is no doubt about that. The feedback gained early in a project will expose misunderstandings and/or different expectations between stakeholders. Early feedback will also keep the cost of change to a minimum.
• Early releases gives the business the option to use the software even with less features (frequent releases will gradually build up the feature list) and hence start reaping the benefits from the investment. Because the features with the most business value are usually prioritized first the software can start paying for itself and for the less important features. And coming back to the previous point I have seen quite a few projects where stakeholders decided to drop the less important features in exchange for changes they would have otherwise had to pay for. This allows a project to stay in budget and deliver totally aligned with the business needs (which of course can change).
• Recently I have stumbled across yet another benefit. Non-iterative (i.e. waterfall) projects tend to never really meet business expectations as business expectations are a moving target. Iterative (or agile) projects tend to not only meet them but also exceed them over the lifetime of a project. In the whole-of-life model we talk about the Outcome - i.e. the benefit realization - rather than the Output - i.e. the software. Watch this presentation here for a graphical representation:[youtube OWvSnYjqOTQ]

The winner of this year’s Agile Advert contest was a recruiting video of ThoughtWorks - actually a quite depressing one. Again, it’s puzzling how much we still focus on basic things like collaboration (e.g. stand-ups or pairing). I haven’t seen a single video (granted I only looked at the high rated ones) mentioning defining what success looks like. Agile software development still seems to be the domain of geeks.

However I quite liked the following video. It is short, simple and straight to the point - a prime example of an agile mind
[youtube FV_9DTJMFZs]

You can view all submitted videos at AgileAdvert.org!