Sprint backlog in Scrum is evil

As is defined by Mike Cohn Scrum encourages teams to breakdown stories in the Product Backlog into tasks which are 8-16 hours worth of effort and which become a part of the Sprint Backlog. These are the tasks which the team commits to completing at the end of a Sprint (which can be 2-4 weeks).

The problem with breaking a good user story into tasks like "Create the UI", "Develop the Service", "Test the Service" etc... and maintaining them separately in a backlog , is that it encourages Scrum Masters to allow different people in the team to pick these bits of tasks of a big user story. So a scenario where Bob (and his pair ?) works on the "Create the UI" task and Ron (and his pair? works on "Develop the Service" in parallel, in order to finish work fast is encouraged in the team.

Scrum templates like those proposed by Ken Schwaber, take it even further by asking people to track hours logged on these tasks. Not only is tracking tasks like these unnecessary, but if a developer does not develop a story end to end, he completely misses out the bigger picture of the architecture. This is where a team ends up with UI experts who know only JavaScript/HTML with no clue of the services layer and Services experts who just develop services without knowing their consumers.

To me, a good user story which has business value, is the only unit of work I would like to track. Developer pairs in a team should be encouraged to work on complete user stories so that they understand the architecture end to end , and have the satisfaction of adding business value to the product they are working on. This is extremely important but unfortunately I have seen many adopters of Scrum mislead by popular Scrum literature available.

Managing Agile team chaos with smaller sub teams

Agile practices work really well when you are dealing with smaller teams. Small teams are bound to be much more efficient and focused. It allows people to know each other well, while having fun at work. Simply put, it reduces the amount of bloat or waste, and it becomes quite evident when you see the team working.
Ideal Size

I prefer a team to be a max of 2-3 developer pairs. Any number more than this calls for a team to be split into smaller sub teams.

Team composition

Ideally based on features or themes. If you have 4 pairs of developers you are bound to be working on more than one theme or feature. A good Business Analyst or a Product Owner should be able to identify these themes in the functionality being developed. If you do not have 2 broad features, try to club the smaller features based on a pattern or a theme. Never split the team based on infrastructure (eg: UI team, Services team)

Align a BA and a QA to be focused on specific themes. If the features are functionally less complex, then a BA and a QA might be shared across these teams.


Split the meetings, making them shorter and more focused

The idea of reducing bloat also applies to the team meetings. Have separate standups among the smaller sub teams. When you have a max of 6-8 people in a standup, everyone will be attentive, interested and will remember what the first person said in the standup when it ends.

Split the Iteration Planning meetings also according to teams which are focused on tasking and estimating features they are developing. You can even have mini retrospectives with sub teams on a regular basis.


Split the card wall

The story card wall tends to clutter up with cards for 6 pairs of developers. Splitting the card wall into separate ones for each sub team helps in keeping the card wall cleaner and motivates the team to keep it up to date.


Handling dependencies across teams.

There will always be dependencies between sub teams. The teams might share some areas in the code base, builds, QA integration boxes etc... A PM or a lead of the whole team plays a vital role here. A PM will have to be part of both the standups regularly and ensure that dependency blockers are removed by teams communicating effectively. As long as the teams are sitting closely, once can always shout out if there is a show stopper !

The whole team can talk about technical dependencies and showstoppers in impromptu developer huddles/technical standups as and when required.


Managing people rotation between teams

People will get bored working on the same feature. Developers will be bored if they were working in a team just fixing bugs or small enhancements. similar is the case with BAs and QAs.Rotation is also important to allow team members to pair with members of the other sub team.

Any rotation between teams can be done at the beginning of an iteration. 1 person swapping in between two 2-pair teams would be ideal. A PM can also choose to limit the number of rotations based on constraints such as knowledge around a particular area of functionality etc...


Better feedback, pair rotation, and self organization

In a 8-10 people team sitting across a table, people can quickly learn about each others strengths and weaknesses. Knowing each other well automatically allows for a better feedback culture within the team. Pair rotation within 4-6 people allows people to pair with everyone in the sub team.

In a small team people have the tendency to self organize themselves. You will see people take on more responsibilities, sometimes a BA playing a PM hat and proactively planning stories for the next iteration. People will not wait for a retrospective to speak their mind about a certain issue, but shout across the table !


Stitching it all together

The Project Manager of the whole team plays a key role in keeping the sub teams focused and on track. For this purpose a PM can conduct an Iteration Close/Planning meeting with the whole team, showing team members where the team stands on velocity, and scope burn down, along with any team rotations for the next iteration. This could be followed by letting the whole team know the scope planned for next iteration.

Needless to say that team outings and other fun activities would involve the whole team !

Needless time tracking in Scrum

On a new assignment, while the client is trying to slowly adopt Scrum (and hence Agile), I have been bothered by the needless time tracking that is proposed by some of the Scrum templates and related literature .

Tracking hours remaining at a task level, or even %age task completion to me is useless. Either a user story is done or not done, simply because you cant do much with a half baked story. A story which is done contributes to the velocity or throughput. Everything else is inventory.

Services have business value

When you are on a project which is about evolving a set of services from an existing application, or building from scratch, there is always a lot of talk on the architecture and service governance aspects.

But if you are a Business Analyst on this piece of work, and you are asked to write stories for these services, you will wonder.. "well how can we showcase just services ?". If you have never done this before, you might even conclude that writing stories without a consumer of the service is not such a good idea. A lot of Agilists might argue that having a services story is a bad user story.

This happens because the fact that "Each Service has business value" does not become very apparent. If you look at Amazon WebServices it becomes immediately evident that each of the services have a set of features which can be sold to customers.

Services are a reality in today's world on the web, and people make money by selling services. A story which builds a service to search a book based on ISBN has business value. It does not need to have a pretty front end consumer for you to write a good user story. A temporary client/UI would be sufficient or maybe even functional tests/specs. It is still a good user story. This essence needs to be spread across the entire team, so that BAs and Devs are on the same page on "Good User Stories" for this kind of project.

Both BAs and QAs have to embrace this along with the developers on the team, and look at ways to apply Agile principles considering this, rather than being dogmatic in their approach towards Agile and SOA.

Challenges in applying Theory Of Constraints to Agile Software Development

After finishing Goldratt's first book, the Goal, I immediately jumped to David Anderson's book on Applying TOC in Agile Management. Preetam also has left some interesting comments on my blog on the differences between s/w and manufacturing which should not be neglected.

One important thing which is still puzzling me at this stage is, if you have to account for throughput, how do you measure value. Value here is the value of a story or a feature. If you are a services shop building an application for a customer, it is upto the customer to determine this business value of a story. Quite often this is not easy to determine, specifically for people like Subject Matter Experts you are dealing with to gather your requirements, who do not deal with sales at all.

In a manufacturing plant, if you have signed a contract to deliver 10 cars for say $100,000. The cost of an engine still waiting in the queue (work in progress) is almost equal to the value of 1 car, $10,000. However the similar analogy is not easily applicable to a software development team. If a story is in progress, it cannot be easily translated to how much $$ is part of inventory.The story might be part of a bigger feature. Also, determining the business value for that feature in $$ itself can be tricky

David's book touches upon in-house IT shops providing IT services (eg: SaaS) or implementing a software product. In these cases, revenue from Sales can be directly mapped to what is being developed. Which is what should happen, in order to increase the throughput of the system, and hence increase the revenue. This is not the case when you are providing IT services to other clients (not in-house).

Some might say you can use story estimate (ideal days or points). Again this represents cost and not value. The iterative nature of Agile also makes it difficult to apply the same principles as a manufacturing plant.

While I am still looking for some answers, the learning on how to deal with bottlenecks, optimizing the whole system, and applying the same to software development, from both the books, are still quite useful.

Dealing with Bottlenecks

Whether it is a manufacturing plant, or a software product team, one can always find bottlenecks. Either they are human resources, machines, tools that we use or processes that are flawed.

2 important things that "The Goal" puts into perspective is that

* The capacity of the plant/team is always equal to the capacity of the bottleneck

In simple terms, for an iteration, if your Dev Capacity is 10 points, your QA capacity is 10 points, but your Customer Acceptance teams' capacity is 5 points, then ultimately your throughput is going to be just 5 points, even if the Dev and QA team work at their full capacity. The customer acceptance team is the bottleneck.

* If you have a bottleneck in between the flow, soon your inventory will go up

In the above scenario, within an iteration, you can easily have a 5 point story hangover/inventory pile up before the Customer Acceptance team. If we continue to sign up for 10 points every iteration, the inventory will easily go up by 5 points each time


What to do with such a bottleneck ?

* In the example scenario, the easiest option to minimize inventory would be to either increase the Customer Acceptance team's capacity. If this is not possible then it is better to sign up for 5 points in each iteration rather than building a hangover story inventory which will have its own maintenance cost. This will make the system more efficient

* Look at hidden costs and try to minimize defects going through the bottleneck. In this case, since we know the Customer Acceptance team is maxed out of capacity, it is better to actually do as much quality testing as possible before the Customer Acceptance stage. This will ensure really low probabilities of a defective story coming out of the acceptance (bottleneck) stage , which can prove really costly.

Another example from my previous project where we applied this was, when we had a major build system crisis The massive Cruise environment we used had hardware issues , and also some issues with software upgrades. Our Quality Analysts heavily depended upon builds from the Cruise machine to start their testing but in this case, the Cruise itself became a bottleneck. On of the measures we adopted was to make sure Business as well as Quality Analysts started testing exhaustively on developer boxes (machines with checked out code). This ensured that defects were caught much before the bottleneck and the bottleneck capacity (which is really expensive) is not wasted on churning out defective pieces for the next stage.

What should we measure on a project ?

While reading "The Goal", the author clearly states that there are 3 important measurements in a system ( a manufacturing plant, which can be extended to a software delivery team)

1. Throughput - Which in a software project would be the No. of story points actually delivered at the end of the cycle (Iteration or Release)
2. Operational Expense - Which in a software project would be the cost incurred (eg: billable consultants, development kit etc..) to actually deliver features (or story points)
3. Inventory - Which again in a software world would translate to the number of stories sitting in transition states and not yet customer signed off (Eg: In Development, In QA, On Hold).
   

The more important point is that one cannot improve on one of these measures in isolation.

Why I say it is important, is because in teams delivering software we often tend to focus on "Increasing the team velocity" without looking at how we can actually reduce the number of "Hangover/In Flight stories".

It is also common for teams to actually sign up for more Story Points in an Iteration or Release in order to show improvement in throughput, which results in more stories in hangover because of some unresolved bottleneck.

The Goal .. is a refreshing read

I have started reading "The Goal". I am just half way through it and am really impressed by the writing style the author has adopted, and how effectively the essence of Lean and Theory of Constraints have been delivered.

The fact that the book is written in a style of a fast paced thriller novel makes it superb. If you are planning to read a book on Lean, this is one of the books I would highly recommend.

Building accountability in Agile teams - Someone needs to ask the tough questions

Agile teams often find themselves in a difficult position when it comes to accountability of the work done. Agile rightly promotes collective owenership, in the codebase, build environment, and even the story wall.While it is extremely useful to have polyskilled people in the team, it should not hamper the need for accountablity on the delivery of a Story, A Feature and A Release.

One way to build this accountability is to ask the critical questions when there are issues in delivery, and tie it with feedback so that the issue doesnt manifest itself again. This can also be coupled with a bit of coaching.

Examples

Scenario 1 : Customer's testing team finds a bug on a story which was delivered to them.

Question (to team QA) : Is this bug breaking the acceptance criteria of the story ?
QA : Yes

Question (to team QA) : Why was this bug not caught when we tested this story ?
QA : Well, this was working fine on the build I used. It broke in the build given to the customer for testing

Question (to team QA) : Why did we not catch this when we ran our automation/regression suite ?
QA : That is because we have some QA backlog on the automation front. This test isnt yet been added to the automation suite

Feedback (to team QA) : Well, that means we need to catchup on our automation first, before developing anymore stories. Now you understand how bad it looks when a basic bug is found during customer testing. Please take this as a challenge that from now on, any stories you test and give to customer, the customer should not be able to find any bugs in them. We should do all that is required so that a story does not fail at any point again.


Scenario 2 : QAs find some basic bugs during testing of a story. A bug which breaks a happy path scenario

Question (to team Dev pair) : Why was such a basic bug not caught during development ?
Dev : Thats because we had to refactoring as a part of another story which ended up breaking this piece of code.

Question (to team Dev pair) : Why were there no unit tests around this piece of code then ?
Dev : Well.. The unit tests were missing because I was finding it difficult to write tests for this piece

Feedback (to team Dev pair) : We now know that having unit tests around this would have ensured that this code would not have broken during a refactoring session. Simply put, if we had test driven the whole piece, we would not have ended up in this situation. I think we need to practice TDD more religiously. in the team. Let us have ahuddle to see how we can improve this. (Maybe look at some coaching on TDD)

It is the Iteration Manager's role to actually ask these questions and make the team retrospect their delivery, time and again, and learn from mistakes.This will allow the team to build more accountability on the work that is delivered.

How do we do both SOA and Agile in a big enterprise ?

The project I am working on currently is a big enterprise application, mostly structured around the SOA model. Since we evolved a legacy code base, the service boundaries have just started to become crisp and clear. We are slowly starting to think of certain teams in the project owning a set of services, and also deciding on service contracts as a norm.

I am now starting to wonder how this model is going to work with Agile teams.

* Will this force us to do Big Design Upfront ? (BDUF)
* Will this force us to have service level teams ?
* How can we write good user stories (which are testable and showcaseable) for service level teams ?
* How can we structure the teams when we have multiple consumers (teams?) for one service ?
* Will this force developers to communicate using service contracts and documents more than unit tests?
* If we try to encourage cross functional teams, will it put a lot of stress on resourcing, with the need of shuffling people around a lot ?

I do not have answers to any of these yet, and a quick look at the Agile community , also does not give me any concrete answers.

Using FreeMind in Retrospectives

So in the last few weeks I attended a couple of retrospectives for my team, and towards the end I facilitated one for another team.

To facilitate I used FreeMind to jot down points which came up during the retro mapping them using the Mind Map. As people were discussing "What could the team do better ?" , I ended up collating them on the map which was projected on a whiteboard. When it came to voting the top 3 points to discuss, we just asked people to put their votes (read color dots) on the whiteboard against the projected map.

Worked nicely. No use of markers, no dirty handwriting, and the team has their mental map right in front of them. The best part is, to send across Retrospective notes as a soft copy, all you need is to export this map as HTML/Word Doc with one click. You can even click print and give each person a copy of it before they leave the meeting room.




Worth a try guys !

Great teams will always be cherished

I have worked on over 10 projects in the last 6 and half years of my career. Sometimes when I look back at them, I cherish the projects which gave me an opportunity to work with a great team, much more than the one where we delivered 2 months ahead of schedule.

A team which worked on a Malpractice Insurance application (2004), and another one building a Leasing application (2006) clearly stand out of all the other teams. In fact one of the teams I work in currently is a close next, and that is probably the reason for this train of thought.

The team dynamics is so great in these teams which immediately allows for a lot of innovative thinking and high performance, since the team would have already got its basics right. It is very tempting to retain these teams as is, and do another assignment, but working in a big organization does not always give you this luxury.

It is difficult to put in words what makes a team great, but I will make an attempt in a later post.

(Note to self -> So strive to build a great team, it is probably what you will remember and cherish for years.)

A must read for wannabe Agile PMs

I am usually quite skeptical about management books, especially the ones that provide general management gyan.

But this book, Manage It, is one I would highly recommend, for wannabe Agile PMs who are making their move from using other methodologies to Agile. It is also a great resource for a Dev/QA/BA wanting to try out Project Management.

The thing I like about this book is that the language used is simple, the author is blunt and to the point. The book gets the juice out of timeless classics (eg: Mythical man month, Code Complete, Agile Estimation and Planning, Peopleware etc..) and puts it into one complete Software Project Management book. There is also no need to read it chapter to chapter, just read what interests you and I am sure you would find a lot interesting in the contents.

Inducting people on large Agile projects

For a small to medium size project, one really does not need a project specific induction. A developer for example, can learn most about the codebase, by pairing with developers working on different stories. A similar strategy can be adopted by BAs/QAs.

But on a large project (eg: around 20 pairs of developers working simultaneously), the scale of the problem (of inducting people) itself becomes big. The codebase is growing rapidly everyday, and so is the business functionality that the application provides. Getting people upto speed for such a project is a big challenge. Moreover, if you have people who are new to Agile, it adds yet another dimension to the whole problem.

One solution is to have a project specific induction. The model which we have seen work well is actual project simulation, rather than having days of overview sessions and brown bags.

In a project simulation model, you try to create a project like setting on a smaller scale, in order to provide a safe environment for new comers to learn and come up to speed with the project essentials.

Some key factors to keep in mind while planning this.

Group size

Try to maintain a group of 4-6 new joinees in one batch of induction. The attendees will be much more involved by simply being in a smaller group setting. Ensuring a good mix of people from various roles would be useful, however you might always not have this luxury. If you find that the latest batch of new joinees are only developers, allow for a BA and a QA to act as part time mentors for the induction.


Timeline

The time line should be at least as long as a typical iteration in the actual project. One should be able to complete a couple of small stories of the project within this time frame. A 2 week time line would be ideal.

Mentor

Choosing a good mentor is of utmost importance for an induction to succeed.

Mentor Developer - A seasoned developer, a journeyman on the project who can work with a few apprentices around him will be the ideal fit for this role. He/She needs to have a decent understanding of the codebase and also the domain of the project. This person needs to play a full time role in the induction and is constantly pairing with developers, on some of the sample stories in the project induction. He/She could also take a few classroom sessions on the project architecture, technology choices etc...

Mentor Business Analyst (BA) - A mentor BA is needed to help write narratives for sample stories which the induction team will work on. A mentor BA should also have a good understanding of the business problem that the project is trying to solve. He/She should also be pairing with any new BAs joining the team. This can be a part-time role.

Mentor Quality Analyst (QA) - A mentor QA should help in coming up with test scenarios for the sample stories which the induction team will implement. He/She should also have an understanding of test automation framework (if any in use), and help the new QAs on the induction team to write new test cases.


Sample stories

One needs to come up with a wide variety of sample stories, spanning across various areas in the project, to make the induction more interesting and a better learning experience.

Simple functional stories

Pick some user stories that are simple in terms of business value they add. The story size should be less than the average size of story in the actual project. Implementing this story should allow instant gratification for the induction team. It might be as simple as showing some information in the UI which is pulled out of a database. Try to have a set of stories in this category, which will allow people to touch different areas of the code. The stories should also add functionality across different areas in the application to make it more interesting for new BAs.

Refactoring stories

In a huge system, there is always potential for technical debt cleanup. Lining up some stories which are purely technical in nature will allow senior developers joining the team to question the code and try their hand at refactoring it, and in the process learning a lot more about the architecture.

Gold cards/stories

There will always be those interesting tasks in an application which people would have wanted to work on but never got a chance to do so because of project schedule. This is the right time to get those out.

Simulate a mini iteration

Try to put together a mini iteration plan. the length of this should be such that at least an average sample story can be completed in the time span. Prefer a shorter time line so that multiple iterations can be packed in the induction. Ask one of the mentors to double up as an Iteration Manager and run the Iteration in a similar model a real one. This would mean arranging for Iteration Planning meetings were one would estimate and task sample stories, as well as end of iteration retrospectives which will allow the team to look back and focus on learnings. Try to also use the same tools for story tracking, bug tracking etc... as the real project

The more closer this is to a real project iteration, the better are the chances for new joinees to get adjusted to the processes followed in the project.

Artifacts

Artifacts might include anything from presentations used in sessions, video recordings of domain specific sessions, or even retrospective notes from last induction. A lot of these will help future inductions happening on the project and hence must be preserved carefully, ideally in a wiki which is easily accessible and searchable, so that new joinees can find the materials easily. In a rapidly evolving project a big challenge is to keep these materials upto date. This should happen after every induction at the bare minimum.


Buddies

Ensure that new joinees have someone easily approachable in their project after they complete the induction process. Assign them a buddy who can help them learn the ropes. This will ensure the newbies never feel lost, which is mostly the case on large projects.

Are you a noise cancelling Project Manager of your team ?

I have heard a lot of people saying a good PM is one who cancels out most of the noise around , so that the team can work smoothly. Like a PM should not only give visibility into the iteration/release on an ongoing basis to the customer, but also take care of ensuring that the work queue is maintained such that there is a smooth stream of work for the release timeline.

In a way he/she is like a noise cancellation headphone, which a developer wears, to concentrate on the code he wants to write, and not worry about anything else. A team should just worry about the stories they have to deliver and the value they wish to provide to their customer and nothing else.

In my view, this is the very first task a new PM should learn to do. The next big task is to actually fix the noise so that the team doesnt need a PM all the time to cut out that noise.

To draw an analogy, if a programmer has to repeat a set of tasks again and again, he will automate that in a shell script. Similarly if a PM finds himself repeatedly doing the same thing, he needs to figure out a process which ensures this happens automatically. An example would be, instead of a PM asking devs every now and then "What is the status of the story?" , create more ownership about that story with the BAs. Let the BA who wrote that story worry about how its being developed and make them collaborate more with developers. The BAs should be eager to see their story being developed by the developers, and that will make sure devs collaborate and show progress to BAs everyday. And the BAs know the story is on track

This not only builds ownership and pride within the team, amongst people who are actually delivering value, but also removed the need for a PM to do a mundane follow up job. If a PM does not think along these lines, it is very hard for that team to be self organized.

Dont work long hours, its neither good for you or the team

Sadly enough, this simple issue of ensuring no one work long hours (>10 - 12) a day, in a team seldom sinks in. When a team is behind schedule, the first thing a novice manager pushes for, is for his team to put in long hours of work. In a developer centric organization, if a manager does this even once, he is immediately in the bad books of people around him. Such a manager is never spared !

However, in the same developer centric organization, some developers may take it upon themselves to finish a certain piece of work, even if no manager asked them to do so. Now this, is considered cool. While I understand that when you are programming a solution to the problem, you really don't want to give up in the middle , just because it is 7pm, sometimes developers slog for the heck of it.

In fact if you are on an XP project, it is better for you to not work long hours. For instance if you ended up working 12 hours everyday in an iteration and you ended up delivering 10 points in that iteration, when a manager looks at yesterdays weather, he will end up planning around 10-12 points of work in the next iteration as well. If this happens consistently, your manager will forget that it was just an exception in an iteration that you slogged for over 12 hours, and it will soon become a norm. A novice or a less people oriented manager will be easily prone to committing this mistake. The next time if you are on a vacation for an iteration, it is up to the remaining people in the team to achieve the same result which you did, which implicitly means they working 12 hrs or more.

While your team (and mostly your managers) will look good in front of your stakeholders, to have finished a lot of work consistently in an iteration, you as a developer will be suffering from a burnout. And you will know quite well that the next time you are not around, your team will suffer, since others in the team might not be ready for the 12 hour marathon.

What I am talking about here is how to achieve sustainable pace in the team. Not only does it give predictability for people to plan their iterations better, but it also keeps the team going for months together without a burn out.

If you are a Developer or a Manager, please do not abuse yourself or the team by slogging out all night for days together !

One for the environment !

It all started when I was sticking a story card up on our story wall, and someone shouted "Dude, how many trees are cut because of our story wall !"

Today our team planted around 21 saplings near JP Nagar 7th phase with the help of TreesForFree The team outing was unique and immensely satisfying for everyone. In fact we decided that from now on we will plant one tree per story we deliver in a release ! (Sripad, who played a key role in organizing this outing, wanted to go to the extreme of 1 tree per story point !)

Apoorv has blogged more about the outing here.

I strongly urge all you agilists out there, who love your story wall so much, atleast plant one sapling, to heal the earth !

(It is hard work in the sun !)

Understanding project risks in a self organized team

Risks and Issues for a project is often a matter of worry for a project manager in a team. When you start asking your team to self organize themselves, one of the challenges is to get each individual team member to start thinking of risks and issues for the project/team.

One of the things which helps during the start of a release is to run through the project plan
through a small group of people in the team, to make them understand what they are signing up for. So if your team has 6 pairs of developers it will be nice to run the plan though with 2 pairs of devs, a BA and a QA, and again repeating it for the remaining set of people. It does not matter whether they are freshers or experienced people, they start thinking about what can go wrong in the project. People start asking more questions on "Why the capacity is so much ?" , and "Why are we planning for these stories in Iteration 2 instead of 1 ? ". More importantly you sign up for a release/project plan as a team and not as a project manager/tech lead.


The team also needs to keep an eye on the risks and issues that they identified and constantly seek solutions to mitigate them. There might also be new risks poppng up. What a team can do in this case is to have a mini risks and issues wall near the team area. It can be an X-Y graph of Risks posted on Likelihood v/s Impact.





Even a white board with risks being updated will do , but what matters is that it resides in the team area. A developer taking a break or a stroll around the team area should look at it and wonder "What can we do to tackle that high risk item ?"

Watching open feedback session helps people to open up

Soon after we did a feedback workshop in the team, we gave everyone options to either use a group open feedback session, a one to one session, or a written medium to gather feedback.

As anticipated, a few of the team members were skeptical about the open group feedback and opted for a one on one session. But we kept the group feedback session open to this set of people as well, so that they could witness how it works.

And quite nicely, a few of the team members who were quite skeptical at one point about being given feedback in the open, decided immediately to have an open group feedback instead of having one on ones.

That move felt that the team dynamics were indeed headed in the right direction ! :-)

Why self organized teams after all ?

I read and reread the Agile Manifesto today. Things which stood out were

"Individuals and interactions over processes and tools "

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

"The best architectures, requirements, and designs emerge from self-organizing teams."

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

People often forget some of these things quite easily. What people remember is "frequent delivery of software", "deliver working software" etc.. This is common among new managers trying to understand Agile , because what is popular about Agile in the market is iterative development, and rapid delivery of software. Sadly people forget that its the team which ultimately delivers the software, and for an Agile team, the things quoted above are indispensable.

The emotional wall

One of the key things a project manager has to do in a team is listen. Listen to people's aspirations, frustrations and expectations. Over a period of time a PM has a mental model of his team which could almost be like a matrix below

Avishek - Sad
Apoorv - Could not be Happier
Rohini - Just about ok

A lot of times a PM has to make decisions considering the above mental model, which is equivalent to keeping the teams emotional state in mind. A good PM will do well in making
these decisions, but then the mental model is still in the PM's mind and not really with the team.

And if the team strives towards self organizing itself, this poses a roadblock. We conducted a simple experiment to solve this wherein we created a wall of peoples names, and asked everyone to stick one Post-It sticky. The stickies were of 3 colors Red - Sad, Orange - Indifferent, Green - Happy.

Now , if a team member sticks an orange or a Red sticky,she also writes the reason for it on the sticky itself. (As long as the reason can be shared with the team). The idea was to update this wall whenever we felt like and see how long it lives.We just called it, the emotional wall !

Slowly I saw the team questioning each other on the color of their post-it. Karthik had a red sticky because he was working on bugs all the time. This made Kiran , who was working on a story to volunteer to fix bugs so that Karthik could be a bit more happier. There were lot of similar instances and it was fun to watch the team take interest in how their coworkers are feeling, and trying to solve the problems within themselves. Yet another experiment in self organizing.