Agile – To do is to be?

November 20th, 2010

“Some say he never blinks, and that he roams around the woods at night foraging for wolves… All we know is that he’s called The Scrum Master”

Just like The Stig (The notorious tame racing driver from the BBC motor show) can show what a sport scar is capable of, the Scrum Master is the one to call when you want to push your development team capabilities to the limit.
The Scrum Master will push, pull, persuade, intimidate, manipulate and use black magic to make your development team perform beyond your wildest expectations.
He will show you how to make your development perform second to none. He will show you how to use that thing called agile. The world will be at your feet – literally!

Nah – you guessed it. I’m kidding.

There has been some debate lately whether Agile is a methodology or a framework? I guess the Stig like Scrum Master above would answer: “Agile is the methodology. It has all these great practices and guides. Implement them and wham bang you’re doing agile!”

My answer is: It is neither. Agile to me is a state of mind. It is not something you do, it is something you can become.
Why? Because agile is all about being prepared. Prepared and open minded to allow your self to act on all the possibilities and difficulties you encounter when developing software.
When reading the Agile Manifesto it is clear, that it was put up as a reaction towards the dominating linear regime of water fall and development by contract of the time. The “we value … over …” is clearly defining agile as a new thing that is in opposition the established regime. This is all very well and I strongly agree with the authors of the manifesto. (It would be somewhat presumptuous not to I guess…)
But try to look behind the values and the principles that accompany the manifesto. Seen together they tell the story of a way of working where we embrace change and interact to build great stuff. And to embrace and interact we need to be prepared.

This has made agile very simple to me. To be agile you need to constantly challenge what you think you know and be prepared to change when you discover new things. Some refer to this as inspect and adapt others call it reflection. It applies to the product you make as well as your processes and organization. You deliberately examine things, reflect on what you find and react accordingly.

Whether you then use scrum, lean, kanban, xp, vanilla or voodoo is something you choose based on the actual circumstances you face. (Mike Cohn offers some great advice on how to chose.)
Common to all these practices is that they provide great guidance and tools that support and develop your capability to be prepared, – to be agile.

Tests should portray the functionalty – not limit how you implement it

August 19th, 2010

I am a great fan of TDD and BDD approaches to software development. The successful creation of emerging software are highly dependent on the close cooperation of stakeholders, developers and testers that these methods encourage.

In my work I have often observed the impact even small and subtle changes in how tests are stated can make.

Consider a simple user story.

“As a user I want to delete selected Xdata”

A test to verify that the implementation of this user story is solved could be stated like this:
StartState: 2 Xdata items are selected from a Xdata list containg 5 Xdata items
Action: Press delete button
EndState: The database contains 3 rows of Xdata

The implementaion is straigt forward:
Select data
Delete selected data from database.

But what if deleting Xdata for some reason is complex, time consuming or requires vast amount of resources in the system. Then the user experience (maybe even for other users) would suffer.

The test, as stated above, requires us to perform the delete in the database. So to maintain the user experience we now have to optimize the data base with regards to deleting Xdata. This may not be desirable, but we have no reasonable alternative.

What would happen if the test was stated like this instead:
StartState: 2 Xdata items are selected from a Xdata list containing 5 Xdata items
Action: Press delete button
EndState: The Xdata list contains the 3 unselected data items.

Now there are several options available for the implementation:
1) Select and delete like above
2) Mark selected Xdata and filter them out in the presentation to the user.  Perform actual deletion in a background job
3) Move the selected Xdata to some other table for special processing
4) …

The point now is, that the test keeps options open to the implementation. Options that will allow the implementation to balance between requirements and features without sub-optimizing towards isolated functionalities. The test stated in the last example are equally well suited to verify the user story implementation as the first one, but is much less restraining on how the user story is implemented.

In short you want your tests to portray the functionality, not to limit how you must implement it.

Keeping this in mind while designing your test cases, will help you adhere to the Lean principle of Maintaining Options.

Roles in agile team based software development

August 17th, 2010

Defining development roles (tester, architect, developer, expert etc) is a great way to discuss the many aspects of software development. By defining roles and their responsibilities, a team can discuss how to arrange work in a way that focus on what needs to be done, rather than on individuals and their skills and preferences. In this way roles can be a catalyst for the self organization of the team.

Seen from the outside of the team, defining roles adds to the visibility of the responsibilities taken on by the team and how the team is handling them..

This is all very nice when the team is forming. As the team matures, the roles in my experience, becomes less and less important.

The roles helped the young team build a common awareness of responsibilities and now, as the team has matured, the team has taken collectively ownership of them.

It is very important as a Scrum Master or team coach to be aware of this transition. In fact sticking rigidly to roles can prevent a team from taking the last steps to excellence.

The mature and high performing team is characterized by its ability to adapt to changes and situations that arise on a daily basis. This is achieved when the team members, with their common understanding of what is to be done, step in and help each other where needed. – Regardless of the previously defined roles. At this stage the team knows what is required and each team member knows how to contribute, even though he might not be the expert in the area.

Succeeding with agile – great book from Mike Cohn

August 17th, 2010

Got hold of Mike Cohn’s new book “Succeeding with Agile” recently. I have been very excited by his earlier writings and had high expectations for this book. And they are surely fulfilled.

Have you noticed what often happens when you read an article in an encyclopedia or dictionary; when you read you discover new subjects that suddenly demands attention and draws you in to read yet another article. Before you know of it, you have read a dozen articles on subjects you couldn’t imagine you would be so intrigued by.

Something like this happens to me when reading this book. I start out to read a chapter from start to finish, but very quickly I get curious to know what Mike’s experience is on some issue that pops into mind while reading. And this is really one of the great things about this book – it is very likely that the issue is covered in there. So reading it becomes like surfing an encyclopedia – great fun! The book is very comprehensive and Mike Cohn share his wast experience with the reader in a way that is immediately useful.

Go read and enjoy!
There is also the accompanying website

Motivation and appreciation

August 17th, 2010

Found this interesting article on motivation. It made me think how motivation and an appreciative approach to management interact.

There is several aspects of recognition and appreciation/recognition. You can:
– recognize the individual you interact with
– recognize your interlocutor’s point of view
– recognize an achievement

The article highlights the feeling of progress and cooperation as two of the strongest motivational factors. That is; cooperation to create progress is a motivator in itself. This is in fact is a strong argument for working in teams.

One thing is to feel the progress in terms of seeing tasks shift from the todo- to the done list. This is of course very nice, but the important aspect in relation to motivation is to have a personal feeling that you creates momentum and progress relative to a goal that has a real and relevant value.

So how can we as project managers facilitate a project culture where motivation occurs and is reinforced through cooperation and progress?

Derived from the appreciative approach and the different aspects of appreciation, we have some strong tools:

– Recognition of team members’ personality and professionalism are the foundation for creating a high performing teams through self-organization and team coaching.

– By making planning an activity within the team you make room for the team members’ positions in relation to how the project objectives are achieved.

– The sense of progress may be reinforced by appreciation of the achievements of the team, when the appreciation is genuine and credible based on open, honest dialogue and when the relevance of the outcome is clear for everyone involved

Recognition is perhaps not a motivational factor in itself, but it is a strong catalyst for motivation achieved through cooperation to achieve progress.