Skip to content

Agile for farmers!

Agile development has proven itself already as a great way of developing software. It is based on communication and pulls the different stakeholders into the project. This is the opposite of the past where we treated development projects as a blackbox, and pushed the stakeholders as far away as possible to avoid change.

Apart the changes in development departments there are a few more areas of discipline that need to undergo change in order to get the maximum out of Agile. I think there is a massive unrecognized challenge for Account Management. Many things are put on the plate of the Product Owner, which actually are activities for Account Manager. I can say that for farmers there is a great opportunity.

I believe that Account management need to manage the engagement of the customer in the development process. There are several things that customers need to do and understand. The list below is what I have experienced. Now my experience is mainly based upon developing products for the B-to-B market with high level of customer involvement.

  • The customer needs to invest time during the project to take part in demo’s
  • The customer needs to allow users to review and provide freely feedback (uncensored feedback)
  • The customer needs to allow communication between their users and the Product Owner
  • The customer needs to understand the concept of development in iterations, concept of backlog and the priorities principle
  • The customer should be able to agree upon functional business goals, not on detailed unrealistic requirements
  • The customer should understand their level of control on created functionality (Here there is a huge difference between product companies and projects, but for both it is valid to say that the customer should not be in the product owner seat)

All in all, this comes across as a great opportunity for Account Management to increase their value and improve the success rate of projects, especially since the success of these development projects depend completely on the engagement of the customer.

Think it makes sense to take our time to educate Account management and Sales.

Securing a design in an Agile process

Over the last few years I have ran several times into the situation where people inside or outside the team suggest to create a style guide for the graphical design of the application. And I have responded to that question in different ways over time.

First time, approximately 7 years ago, I got confronted with this question, I looked at the problem and believed that a style guide could be a solution to get rid of the detail differences in the implementation of new functionality. So, having that believe, we made a guide covering each type of GUI component and how the look and feel should be for the application. Great piece of work with two major results:

  1. Within 3 months after completion we were confronted with new GUI components that were not covered in the guide.. now what?
  2. Within a few months no one looked at the document anymore

Conclusion is that the work spent was wasted and the original problem still existed.

The second time I was confronted with this situation I did not wanted to run into the pitfalls of the first time. I understood that evolution of the application will go faster than the evolution of a document. We made a number of concept screens. More or less a number of mood boards providing more an atmosphere the screens had to comply too. Nice idea and it dealt with the issues I ran into before. But unfortunally, every developer had its own idea on how it looked and felt like the mood boards. As a product owner I also gave my opinion and had the final saying on what was released. But I am not a graphical designer, so a little more successful, but still a huge opportunity for improvement.

And, of course, I did get confronted with this issue again. And I decided to rely on people, instead of artefacts. Instead of creating document, mood boards or examples, we decided to pull in the graphical designer. We decided to, as far as that was possible, make the graphical designer part of the team. This way, an esthetical eye was constantly watching us while we created functionality. Making sure things looked like they should, with the highest level of consistency.

Now this graphical designer was not a full time member of the team, but we did made sure he felt like he was part of the team. That each team member knew him and had access to him, he was also part of the skype group so it was easy to quickly share a screen with him and solicit feedback on what was created. Needless to say that this worked as a charm. Of course the vulnerability of this solution lays in what to do when people are absent or choose to leave a company. But however much managers dislike it.. companies are made out of people, and have to be special people if you want to achieve special things.

As a product owner your live revolves around ‘As a’

 

It is the start of almost every story you deliver to your team. A story that is build up out of, most of the time, a single sentence. The single sentence that forces the reader to impersonate themselves into the role of a user, administrator or any other person that uses the application. The power of those two words in enormous.

Three letters puts the reader of the story instantly in the ‘imagine’ mode. So a developer is forced to think as a user or administrator when he/she pick up the story. It sound trivial, but it is the essence of successful development. Everybody should have the customer or user in mind. Those two words are forcing developers to do this

So it is not only the Story you write that starts with these 2 magical words. It is far more. You are constantly utilizing the imagination of yourself and your stakeholders to drive the product further.

You, the Product Owner, you should be able to view your product as a user. You should be able to view your product as a customer and you should be able to view your product as a Developer. It is the core attitude and talent you need as a product owner. The ability to look at you product from different angles and see the benefits and hurdles for the different stakeholders.

Help, we have created a monster!

When a child is born, as a parent you are proud beyond anything. You nurture and teach your child to become a better parent then you are. But there is a chance that your kid will grow into a direction you actually despise.
Scrum is showing signs of a development like that. Full of proud it was placed in this world by Jeff, Ken and the others, raised with beautiful principles (the manifesto), but at a point it decided to go its own way. This week I ran into two symptoms of this:
1. A company offering consultancy for top down implementation of Scrum
2. A company offering Story writing course
Both are, in my belief, the opposite of the essence of scrum. Scrum comes from within an organisation and cannot be dictated. To stay close to the metaphor, it is like a man deciding that his wife should become pregnant… he can decide whatever he wants.. but she calls the shot on this one! Top down.. how do they see that? A detailed waterfall plan for implementation of scrum with toll gates and time lines?Writing stories, while the base principle is communication over documentation. This is how all the beautiful documentation standards of waterfall based developments started. I see myself ending up in countless meetings about documentation standards of stories. That idea should scare you enough and does not need any more details or ridiculing metaphor.

Stay agile and don’t buy this! 🙂

Don’t write great stories!

Image

Triggered by an earlier post on the Certified product owner group by Jeffery I started thinking about what defines great stories… That thought took a while when I discovered that there is no definition of a great stories. And, actually, thinking of improving stories is kind of all wrong.

I am sure we all experienced the situation where we walked out of the planning meeting thinking that for the next sprint planning we will have better and more detailed stories so the meeting will not take that much time. This is, I think, a mistake. It is not about the time the sprint planning takes. It is how the story is demo-ed! And of course, there are many things a PO could do to prepare the stories, but the goal should never be to minimize the time the sprint planning takes. If that is the case the PO will start to write more and more things the team could possibly ask, and that starts to look pretty much like an oldskool requirements document…

Another fundamental mistake for product owners is to see the story as their deliverable. And for some “story writers that call themselves product owner” it is the only deliverable on which their performance can be measured. If the product owner is not responsible from beginning till end, the story is the point where the responsibility is transferred. So by elaborating on the story, the blame is also transferred .

Many times single sentence stories have let to perfect result, but also many times I had to deal with teams that instantly got afraid for hidden requirements and say, without reading, that a single line cannot be enough. Actually almost the same when the PO only writes stories, the focus is on stories.

These two elements, lack of responsibility of the PO and the fear of blame of the team all exist for a long time. These are for sure the seeds that have given us nightmares called for example prince2. If the role of PO is clear and the PO takes his position stories do not count, results count. Of course stories are needed, and they have to be split up in a logically way, and in order to show the team that you take your work serious, they have to look good. But the result of the team counts, and if two words are enough to achieve that, that is great. But as a product owner you always need to know what you want and always be available for the team to elaborate on that.