Informative workspace – the scrum kiosk
One of the biggest challenges you have in a organization with 6 scrum teams with some people remote and different stakeholders introduced at different levels in the scrum methodology, is sharing some significant information about the status of the development.
Each scrum team tends to create its own working style, a sort of ecosystem that best fit people in the team. The challenge is to encourage that everyone, inside the scrum teams, but also external stakeholders, can share the same big picture.
One way to encourage better mindfulness amongst the entire team is to create an “informative workspace”, something that tunes anyone in to the status of the project.
Better than using my words to explain it, I will borrow an excerpt of James Shore & Shane Warden’s book The Art of Agile Development.
Your workspace is the cockpit of your development effort. Just as a pilot surrounds himself with information necessary to fly a plane, arrange your workspace with information necessary to steer your project: create an informative workspace.
An informative workspace broadcasts information into the room. When people take a break, they will sometimes wander over and stare at the information surrounding them. Sometimes, that brief zone-out will result in a aha moment of discovery.
One recent improvement we have done to make our environment more informative is what we called the scrum kiosk.
We installed a monitor on the wall and we slide-show projects facts: deadlines, status reports, process information and reminders, burn down charts and so on.
It’s a live snapshot of the current iteration and release.
We’ve implemented it in few simple steps using the following software:
- DejaClick: Firefox plugin for web browsing recording. It automatically reproduces the main paths done browsing our internal systems and wikka pages
- a Fullscreen Firefox plugin
- a simple Java app to put everything in an infinite loop
You can see some pictures below.
In addition, since we have remote people, we plan to stream the content of the monitor to our internal network, so that everyone can see what’s displayed. Indeed it is not the best solution, but it is something in meanwhile we find a better idea.
Any comments or suggestions is welcome!
Brown bag agile lectures
Recently I’ve introduced the concept of Agile Lectures in Funambol (see here)… aka Brown Bag Lectures.
Below you can find the list of the lectures done until now…. a successful initiative in my opinion: 30 minutes every week, informal, cookies, coffee and beverages… not a meeting, more a coffee break (a little brown bag meeting).
Agile Lectures:
01 Sep 2009
- “The Art of Agile Development” Book- Chapter 6: “Collaborating – Trust”Links:
22 Sep 2009
- “The Art of Agile Development” Book – “Incremental Requirements”
29 Sep 2009
- “Fearless Change Patterns” Video Interview with Linda Rising – http://www.infoq.com/interviews/Linda-Rising-Fearless-Change
06 Oct 2009
- “Agile Estimating and Planning” Book – Chapter 4: “Estimating in Story Points”
- Links:
… continue…
… maybe we could even do it live online also for external people 
Cost of unit testing
I found an interesting article about the topic of how much unit testing cost: http://misko.hevery.com/2009/10/01/cost-of-testing
Agile lectures
Recently Edo, our scrum master, introduced a new initiative that I particularly like: agile lectures. From his presentation:
What is it?
30 minutes of our time every week to read and comment together some excerpts of Agile (Books, Articles, Tutorials, Videos).
We’ll start with some paragraph from the book “The Art of Agile Development”.
Why?
Because learning is an on-going never ending process, we still need to learn something and Agile is hard to maintain
How?
With a projector in a relaxed environment with coffee, tea, cookies. Reading and commenting together. Remote people will join via webex and have virtual cookies
When?
Every Tuesday at 4.30pm until 5.00pm (CET).
Where?
In the meeting room in Pavia’s office (the cave) and via webex for remote people
Who?
Everybody is welcome to the lectures. No need to send confirmations, just come in the cave and join the lectures.
The reason why I like it so much is because we have been realizing that between agile and pragmatic agile there is a huge distance. I see pragmatic agile as the every-day agile, with the environment you are in, the people and the teams you have, the habits and cultures each group of people establishes over time. These lectures are a way to understand how agile and pragmatic agile can get closer. With this I mean that we see how things could be done differently, so that we talk about it and internalize it. I learned that at the end some people are not interested in principles or values at all. They are just interested in their daily job and in how make it better. Agile lectures are a good way to talk about real every-day experience in the context of agile practices.
As a … I want …
One of the key aspect of agile development is expressing requirements in user stories. It is one of the things that I like more, because it encourages developers to think always like a user.
However, in our switch to agile I’ve seen US using the most disparate roles between “As a” and “I want”. The most common mistake is when a technical task is expressed as a US using expressions like “As a developer I want to merge the tag into the trunk” or “As a product owner I want to know the size of a the MEA feature”.
For this reason I decided to identify which roles we use and introduce them to the team at the last demo meeting. Using a role not in the set below should be a big smell that there is something wrong.
The first role we use is the user:
The user role
The user is who is using the user interface of our software. This is primarily client oriented, but not in all cases.
As some of you is wondering, yes, the command line is a user interface as well. But it is a particular one, used mainly not from the final users, but most likely by system administrators. The system administrator is one the roles we selected from our us:
The system administrator role
With our software there are also users whose duty is to help other users. These person are the portal administrators, who administers the portal users and other portal functionality. The portal administrator is therefore one of our selected roles:
The portal administrator role
Finally, an important aspect of our software is that it provides APIs and SDKs other developers can use to build application on top of our framework. These are definitely a special case of users, for which we want to build features. The developer is therefore the last one of the roles we use in our backlog.
The developer role
Note that “this” developer is not the development team, which therefore has visibility to all Funambol code. This is a developer that wants to access a limited set of the source code, or maybe not even the source code, but libraries or APIs delivered in binary form. It is who uses our software to build something else, not who develops the software itself.
Many thanks to Francesco Mapelli, the author of the nice “omini” that represent our user stories roles.
The risk of nano-management
One of the things agile practitioners and advocates fight, at least in principle, is project micro-management that is often associated with waterfall software development. Agile methodologies replace the need of having a so hated project manager that controls and then commands any aspect of the team and project with an informative work place and process that encourages sharing also the status of the project. Having a release split in iterations and then user stories in each iteration makes it easier to everybody to figure out how things are going.
This is fairly true, at least looking at our experience, where the new process has been accepted with favour at all levels in the company. In fact, some interpret agile processes like chaos reigns and where any sort of planning is banned. At the contrary, because agile software development embraces changes, an agile process asks the team to diligently and regularly check where the actual plan is compared to the original plan. To do so, inefficient and always-out-dated gantt are replaced with attitude and “tools”.
The attitude of an agile team is to make a plan at the beginning of an iteration or release and adjust it over time. This must not mean that the team is not in any way committed to the plan. The team should do all it can to follow the plan, but the goal is not to adhere to the plan, but to deliver value. Even the concept of “plan” may vary from team to team or amongst different agile processes. The plan could be a sequence of tasks, an high level gantt or even just a prioritized backlog. The goal of the team is to deliver what they promised, the way they achieve it is team responsibility only.
There are also great tools agile practices introduce or make use of to help teams to better perform. One of the best one, in my opinion, is at the basis of iterative and incremental development: user stories. I believe user stories are a powerful tool in the hands of all stakeholders and teams because they represent the atomic (at least at a certain level) piece of work around which a number of other concepts are attached. The first one, for who, like us, estimates in story points, is the size. And when you have a size, and an iteration, you have how many story points the teams make in a certain amount of time, which is their velocity. With user stories and size you can track the amount of work done or to be done over time with burn down or burn up charts. With user stories teams can commit on definite amounts of work and make very clear what’s get done and what not.
In addition to what more related to the process, often agile processes bring a number of other techniques to develop better software or increase productivity. All this is completely under the light of the stakeholders and managers, and in my opinion this is a very positive aspect of agile principles.
However (you knew this was going to come… 
), stakeholders and managers must be trained or socialized on the real goal and meaning of this tools. Some of these tools are so easy to pick up and give so great visibility that I am sure all managers love them. But if the meaning of the tools is misinterpreted or distorted, than it becomes an issue, because something that you think is useful for your team turns against the team at managers’ eyes.
A good example of what I mean is velocity. It is so easy to associate velocity with productivity or team ability to deliver on time. It is a simple number that may go up, and you are happy, or down and you are unhappy. But if you take just that number, ignoring where it comes from or what’s behind it, than you can easily go off-road. For instance, let’s assume the team is going through a tough period, some features revealed to be harder than expected, more legacy code than expected required refactoring, and maybe the team changed its composition. The sum of these factors will certainly take down the team velocity. If you do not trust your team, you will probably start to think that the team is not able to deliver, so you trust them even less. When managers see (or perceive) bad results they have to react. It is their job and role. This can lead to a situation where managers, given the number of tools that provide so good knowledge of what’s happening in the team, can be tempted not only to start to micro-manage the team, but to even nano-manage it (“why this user story is so big?”, “are you sure it is 10 s.p. and not 9?”, “why are you working on this u.s. now instead of later?”, “can you send me an email with all task you have done at the end of each day?”, “the burn down is not going down, we need to work more…”, “shall we put more resources?”, “c’mon a normal developer would take half of the time to do this…”, etc, etc…)
I am in that category too and so I am the first one tempted to go on that path. Instead, I think we should resist that temptation and keep trusting the team. This does not mean of course to trust the team blindly. We must make sure the team understands there is a problem and therefore acts to fix it. The team must know very clearly what are the areas of concern and what the factors of unhappiness, but still they deserve respect for their work and trust their willing to deliver the promised value. They may need help, and here is what managers are for: to listen the teams needs and help them to see how to overcome the difficulties. Help is also challenging the teams and their decision, to help them cross-check their assumptions and decisions. But the worst thing we could do is stick an ideal burn down chart on the wall and teach the teams that that is what they have to do
Scrum READY state ?
Recently, in a post on the extreemprogramming-it list I read a post quoting the following two links
- http://blog.xebia.com/2009/06/19/the-definition-of-ready/
- http://blog.xebia.com/2009/07/04/flow-to-ready-iterate-to-done/
They introduce an interesting concept in scrum development which has to do with the interaction between the product owner and the development team: the READY status.
In the first article, READY is defined as follows:
READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the “supplier” is the Team and the “client” is the Product Owner, it’s the other way around with the Definition of READY: the Team is the “client” and the Product Owner is the “supplier”. Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: “Ah, we get it”.
I thought about it a little bit and I have to say it does not convince me. The first thing that makes me hesitant to buy into it is that it introduces a sort of phase.
In explaining the use of this state, the author says:
In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.
And of course this is a very good proposition. But is a READY state really necessary in order to achieve that goal? What if for the most different reasons it is difficult to reach that kind of READY state. And why we exclude in principle that instead a team should self-organize to even overcome a lack of READYness?
One of the agile practices I like is that you want to spend your precious time on things that have enough value. This also means that you can accept a level of un-READYness under certain circumstances. For example, you do not necessarily need all user stories to be completely ready when you do release or iteration planning. The goal is first to identify what can fit a release or an iteration and only when a user story has enough value make sure that all aspects are covered, that the US is of the right size to fit the iteration, that the implementation strategy is define and maybe the tasks identified.
I also do not quite like the fact that the READY status remarks slight separation between the product owner and the team, while instead I like more to think about the PO is part of the team. The team works together also to make sure the user stories are ready and it is not a precondition to start a sprint. The last thing you probably want if you are doing scrum is that the teams are waiting on a precondition to be triggered in order to produce value, exactly like if a developer should wait to start development until an architect has done the design.
Facing reality
I’ve been asking myself what’s the biggest and hardest challenge in embracing agile development. There are a lot of factors in play and it is not easy to clearly see what gives us the biggest pain. There have been also different phases in our way of adopting scrum, each with its challenges.
The human factor is surely one of the most interesting challenge because there is no way to foresee how people will react to the introduction of a development process that asks them to self-organize and make the team’s goals their own goals.
The practices their-self are challenging as well. You get lost very easily when you do a lot of changes at the same time. This is particularly true when you are experimenting yourself all those changes, because maybe you do not have the luxury of a budget for someone that can help you. In any way, I strongly believe there are things you have to learn in the hard way, no help other than your experience can show you the way.
Legacy code is another big obstacle in the way of being more agile. You would like to do more, be able to confidently change things; instead, you often fall in the chicken-and-egg problem that becoming able to do so means to spend time to refactor a big chunk of code. Since it is expensive, you do not start, piling technical debts over technical debts.
But the most challenging experience of embracing scrum is facing the reality. The essence of scrum is very simple: you have a check point of all your work, assumptions, plans, in a very short time-frame. This is terrific, because you know almost immediately how you are doing. But the reality can be something you and your stakeholders are not ready or willing to know.
When you do a long term plan, you keep the hope your plan is good until very close to the end. Since the deadline is far away, you keep the feeling that somehow you can catch up. There is usually not any real and concrete reason for that to happen, but you still believe it. The scope won’t be significantly reduced until the end, the resources will be the same for duration of the project, customers will keep bugging you with bugs and requests, you will keep read tons of emails per day. But still, you believe you can make it. There is something in the back of your brain that tells you “we cannot make it, we cannot make it…”. But you don’t hear it, and you keep believing something magic will happen.
Do not get me wrong, this is done all in good faith. The best product owners are the ones that see possible what everyone else considers impossible. This makes them more reluctant to consider that a plan is not achievable. They want the teams to have a “yes, we can!” attitude and they do not want to hear “sorry, this plan is not doable”. On the other side, the teams want to make their product owner happy, therefore tend to say “let’s try and see”.
I observed a very interesting phenomenon when we switched to two week iterations. Most teams over-committed so that after one week most of the stories were still not done. Asking the teams if the commitment were still confirmed, they were still confident they could complete all the stories. I was becoming every day most worried and the teams kept being confident they could do all the USs until the very last day. There was not any real reason to this to happen… but still the teams were confident. Do not get me wrong, I appreciated a lot the teams attitude of trying to keep the commitments to what they promised to deliver, but the result was that their goals have been constantly not met and the stakeholders have been seeing the teams constantly fail on their commitments. This resulted in unpredictable velocity and in the teams and stakeholders constantly frustrated by the missed goals.
But scrum asks you to do something different: to look at your self, at your teams, at your stakeholders and do not lie. Scrums allows you to achieve your goals because you first of all have to face the reality. The reality of your team, of your resources, of your possibilities, of your knowledge. Only if you accept this challenge and you accept you have to make a plan that works given your real conditions you will be able to see your progress iteration after iteration. Only in this way you can see your weaknesses and work around them in the meantime you work to fix them.
However, sometimes this is not easy to accept. You may be frustrated and wish you have a different team, different deadlines and a different budget. You will be tempted to point your finger to scrum just because it opens your eyes.
But if you resist to that temptation and start to accept reality, you will have the great opportunity to fix what’s wrong and therefore to constantly improve. End eventually, you will be surprised to meet unhoped results.
I believe there are two factors that allow a development team to face reality:
1. Trust each other. The development team shall always keep in mind that what the PO is asking is what will make the product a successful product. POs shall always keep in mind that the development team wants to build a successful product and put all its best efforts to make it happen.
2. The development team needs to gain the confidence of saying, without illusions, what’s achievable. The team needs to learn to say ‘NO’. Plus, the development team must learn to provide alternatives. Firm ‘NO’ must be exceptional. Most of the times a ‘NO’ should be accompanied but alternative options.
What I often tell my team is that we can accept we do mistakes because nobody is perfect. What we cannot afford and to not improve. Facing reality is a precondition to improve a team.
Principles and anti-principles
Who heard of agile software development very likely heard of the Agile values and principles. These are quoted in the agile manifesto that you can read here.
I think that the fact that agile methodologies are backed by that conceptual framework is extremely effective and powerful (in addition to be a genial marketing move): it gives you a common background or system of values to think about when you are facing a problem and you are trying to figure out a solution. I believe the power of agile principles and values is the charge of positivity in finding good solutions that will make you a step forward in the right direction.
What I am realizing and experiencing lastly is that agile principles and values have also a negative charge, the dark side of agile principles… Let me explain. I consider a positive charge when in front of a problem we think at the values and they show me the right path. For example, in front of a customer that changes his mind about a feature, instead of pointing out that in the statement of work we said the features would have been different, we work with the customer to see how we can fit the change in the plan done together.
An example of negative effect of the principles and value is when they are used like a shield, or worst a ax, to make sure that something we do not like does not happen. I do not like to write documents? then I bring the principle “working software over comprehensive documentation”; I do not like this or that tool? then “individuals and interactions over processing and tools”; somebody asks me about my missed commitments? then I bring “responding to change over following a plan”. In other words, instead of trying to understand the underlying problem and finding an agile solution, I sometimes see the tendency to hide our-self behind the excuse that things should be done differently. “You want to be agile??? then you must follow the manifesto!”. How to do it is considered irrelevant, there is always another better way to do anything. What the underlying issue or problem that we want to solve is not important. The only thing that matters is that if you want to be agile you MUST follow the rules…
To me this is very anti-agile and turns the principles in anti-principles and the values into dis-values.
I think that part of the problem is that the agile manifest is often read superficially. In the above I used principles and values almost interchangeably, like they were almost the same thing. I’ve done it on purpose because it is what I hear very often. But reading carefully the agile manifesto, there is an important distinction between the two. The manifesto says
...Through this work we have come to value:
1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan
And after that:
That is, while there is value in the items on the right, we value the items on the left more.
The first thing I would note is that those are the Values. They are not the principles.
Secondly, what the manifesto says is that even recognizing the value of the right side of the sentences, the left part is more important.
The two observations above are important IMHO, because on one side, the agile value system shows you where you should look at when in doubt, on the other side they implicitly express that there is a balance you have to consider between the agile value system and other value systems (customer’s organization, your organization, business constraints and so on).
Where the principles come from then? ehehe, I do not know for which reason, but they are after the list of the Agile manifesto promoters and the copyright information, that is below where you usually would stop reading a web page. If instead you scroll a little, you will see the “Twelve principles of Agile Software” link. This is a very interesting reading, actually I would say the most challenging part of agile development. Those are the Principles and they are quite demanding. They start from putting at the highest priority early and continuous delivery of valuable software, to the delivery of working software frequently, to getting together business people and developers and so on.
The difference between values and principles is that the latter are a kind of normative guidelines derived from the values. I said guidelines because who is serious about software development knows that each team is different, each person is different, each organization is different. Therefore the challenge is always how to apply the agile values in a specific environment, putting in practice at the best in the given circumstances the principles. What’s funny is that I am sure that waving the agile values you could sustain that any of the principle should be avoided. For this reason it is not only important to have the values in mind, but also the principles. When we see a practice that seems in contrast with the values we should also ask why it is in place, and if it aims to achieve any of the principle. If so, we can pic of the two choices: propose how to improve things, or waiving the values and shield our-self behind them…
-
Archives
- December 2009 (1)
- October 2009 (2)
- September 2009 (3)
- August 2009 (1)
- July 2009 (2)
- May 2009 (1)
- April 2009 (1)
- March 2009 (1)
- February 2009 (3)
- January 2009 (3)
- December 2008 (1)
- November 2008 (4)
-
Categories
-
RSS
Entries RSS
Comments RSS
