What is in common between performance review and planning poker?

My team of coaches meets once a week for a very special ceremony we created called CPI, which as you know, stands for Continuous Process Improvement. It is our opportunity to talk to each other about our findings, things that work, parking lot items that we would never prioritize for other meetings, and just to spend time with like-minded people. We agree, sometimes disagree, but it always feels good like the time worth spending and the inspiration for new exciting thoughts, approaches, techniques, and just the energy you get when you talk to people who have similar values to yours.

But this posting is not at all about our CPI time. The reason why I wanted to mention this atmosphere of mutual respect and complete trust is that I and my colleagues were talking about maintaining relationships with Agile practitioners as an organization, and I spoke about cultural differences. I mentioned that when I came to US as a student and someone would ask me "How are you doing", I would start telling them how things were and thinking that they asked about they are genuinely interested in knowing the details - otherwise, why would they ask? (I did not mention it to my colleagues, but interestingly - and I think it describes very well the atmosphere of Stanford University in mid-90's - it took a few months before someone explained to me that this is not what was expected. During the first two months or so everyone listened to me and nothing challenged the impression that people genuinely cared. And maybe they did, just considered me weird, but still cared - hard to figure out now.

Two things happened to me recently that revealed interesting similarities. One - I have been conducting annual performance review meetings with the scrum masters who report to me as their functional manager (we have a matrixed reporting structure, and my role as a functional manager is to develop scrum masters from Agile best practices standpoint and in terms of their career growth, support them, and through them support our Agile teams). I collected light form of 360 feedback - from teams, business stakeholders, Agile community, and shared my summary with each of the scrum masters. Scrum Masters felt these conversations were helpful. They were helpful for me, too.

However, a popular perception is that if we have trust (which I hope we do) and provide open feedback to each other on an ongoing basis (which I know we do as well), then annual performance review are not needed. At some point, I thought the same way. And then, my attitude changed. Each of these conversations triggered a really great discussion - discussion about goals in life, difficulties that they overcame, achievements they are proud of, dreams for the future and for their teams. Each of the conversations was rewarding and energizing. A simple topic related to teamwork would reveal challenges and victories, and we would talk about how the team is gelling together and what we can do to help the team achieve higher productivity and joy in their work. It is like answering with your biography to the question "How are you doing?", and this biography is so meaningful and relevant that you do not want this person to stop, even though it is not what you expected.

This morning, I read December blog posting by Dan Mezick in his blog. He was talking about estimating as a team learning experience, and he spoke about Planning Poker. He said that the Planning Poker is not meaningful by itself, but as a ritual and a team-learning effort. I agree with Dan: planning poker's value is in that it promotes conversations about complexity, unforeseen pre-requisite, configuration changes no one anticipated, and other relevant tasks. Similarly, annual performance review. Even if the information presented in it is not new to the participants,  there is a  value of having it, because

---- and this is what there is in common between both -----

both are powerful triggers. Annual performance review triggers important conversations between employee and his/her manager, it makes us think of what has been achieved during the year and how to become better in what we do. The secret is: don't try to use this ceremony (isn't it a ceremony in scrum understanding?) to assess individual performance. Similarly, the planning poker triggers story discussion for the team, where new and unforeseen things may be discovered that will add complexity to the story, but don't expect the estimation to be accurate. Both may serve a different that their stated purpose (which is for performance review to assess performance and for the planning poker to estimate), but both are very helpful and important. Same goes for answering the "how are you doing?" question - now I get it :-)

Commitment vs. Forecasting

I believe in simple human values. That is why I call my blog "scrum with a human face". You probably noticed that I write less about processes and more about people with their feelings and perceptions. I am not an idealist. I cannot even figure out where people worked harder - at my previous employer who did not care about people or at my current employer who cares about people a lot. But I definitely know where people are happier and this is sufficient for me to make a choice. You can call me old fashioned but I still believe in promises, happiness, and good will.

You may argue that promises are broken so frequently that the value of the concept is dying. Maybe it is, maybe not, but I think it is values not processes that made Agile such an incredible framework. What resonated with you that you first heard about scrum? Sprint planning and sprint review meetings, or values of respecting people over processes and collaboration over documentation? Anyway, I am not writing this blog to remind you of Agile manifesto. The reason I am writing it is to talk about the power of commitment.

I do not know if it is normal to break promises nowadays. Some people do, of course, but are those people your friends? someone you respect? someone you want to interact daily at home or at work? There is still respect for those who keep their promises and I think each of us does our best to meet our commitments, even if it is difficult sometimes.

In scrum, it may be impossible to meet a commitment sometimes. Having that said, it is important to do two things:
1. As soon as I understand that I may be not able to meet my commitment, I make it transparent to the team at a stand up or as soon as I know. I ask advice from my team members or ask for their help. In about half of the cases, this works!
2. If there is an external dependency (data not available, tool not procured, environment issues, or dependencies on other teams), I ask for help from my scrum master, research workarounds and short term solutions (mock up the data, try a different tool, etc.) and make the other party aware that they are a blocker for me asking whether they can suggest an alternative solution. In my team, we use a physical task board, so we put those dependencies on a different color stickie. When stories have a large number of blue stickies (external - outside of the team - dependencies), we estimate it higher because it normally takes longer to resolve.

So - when at Agile Day NYC 2012, Ken Schwaber spoke about the update to 2011 scrum guide to replace the concept of commitment with the concept of forecasting, it did not resonate with me. Please do not misunderstand me - I respect forecasting, it is important, and that's what we do every sprint. But take commitment out - and it is almost like saying "let's not give promises because people don't keep them anyway". But some do - and this makes this world a better place.

There are many good points in talking about "forecasting" - a great posting on the topic is here, so I am open to comments and other thoughts.

In my next posting, I'll talk about another "scrum with a human face" topic - how to achieve balance between referencing impediments during a sprint review sessions and finger pointing.

Scrumban in a Nutshell (Part II)

In our PMI presentation, Irina and I spoke about a single team's journey from waterfall to scrum to scrumban. Transition from waterfall to scrum for a project like ours which had fluid business requirements, which were discovered as we developed new functionality and provided sufficient data for re-engineering and creating new business rules, was natural. It eliminated frustration from the business stakeholders and increased team's moral, provided business results that were needed. But it was not the end because once the team established repeatable rhythm, it became clear that planning was a challenge, and the old problems we thought we successfully overcame with transitioning to scrum, came back. 

At that time, I have not read Corey Ladas book on Scrumban yet, nor was I familiar with a brilliant definition by Yuval Yeret that Scrumban takes scrum outside of its comfort zone, but we felt that we are producing waste and at the same time, throwing in too many stories we are unable to complete, our planning was obsolete before we left the planning session, so it was clear we had to become lean. So the concept of scrumban emerged for our team as an attempt for lean scrum. 

While attempting to go lean, we did not want to sacrifice the rhythm that we achieved and the cadence we established  Business stakeholders enjoyed the demo and appreciated knowing when enhancement requests will be worked on. The team liked the concept of set iterations and repeatable ceremonies. So, we wanted to keep scrum cadence and become more lean. Scrumban became our answer.

So, to reiterate, our objectives were:

1. Keep the cadence of ceremonies - sprint reviews and retrospectives were the two practices working well for the business stakeholders and the team.

2. Set up clear objectives - having a goal is natural for humans. Without meeting specific objectives and no goal to achieve, work becomes dull and besides, there is no reason to celebrate!

3. Deliver prioritized work to the customer - work has to be prioritized, discussed and agreed upon. Maintenance requests include fixes and enhancement, and some of those enhancements are critical to the business, so "first come first served" approach does not work for them.

4. Minimize waste - no reason to do planning if the inflow of stories is high, and prioritization is the hey. No need to plan if it becomes obsolete before the team leaves the planning session.

5. Provide flexibility customer needs - ability to shift priorities as new stories are submitted.

6. Minimize work in progress - avoid overwhelming your team members with dozens of urgent requests in flight. This becomes stressful and unproductive due to context switching and frustration that incomplete work creates on both sides, so the idea was to establish a flow and minimize work in flight for the team.

As you can clearly see the first three goals map to scrum and the second three map to kanban. By adopting scrumban and customizing their workflow to the specific needs of the business system created, the teams were able to provide better visualization while providing visibility the users needs and objectives the team committed to. Here's the team's scrumban board:

For a good summary on how scrumban combines scrum and kanban, I would recommend this brief yet informative posting.

There is much more to it because we haven't yet discussed measuring progress and forecasting in scrumban. Post a Comment if you'd like to talk more about it, and we'll continue the topic!

Scrumban in a Nutshell (Part 1)

Scrumban is becoming  a buzzword, and if you ask me, for a reason. People like structure. We are cyclical creatures. We set goals, work on making them happen, and set up a new set of goals. We need a direction to go and a sense that we will get there. Who hasn't ever set up New Year resolutions? We are in the beginning of the February and my personal ones are fading already, but I still remember a nice feeling of setting them. How does this apply to Agile? - you will ask me. This is why I think it does.

Last week, my colleague Irina Miretskiy and I made a presentation at a New York Chapter of the Project Management Institute about our case study. The project we worked on started as a very traditional waterfall project. The goal of the project was to create a reporting system for a company which was in the process of changing its business model. Reporting functionality included application of multiple business rules to slice and dice and shape up the data to model how the business is structured. The complexity was that in the middle of transformation no one understood yet how the business would be functioning. Just one example: image student enrollment in a test prep class. As a Sales manager, you need to assign a sales credit to a sales rep who signed up a student (or as an alternative, you can roll up all sales for a physical test prep center and split the enrollment credits based on a set of specific rules). However, if you are switching to an online model and your classes are no longer associated with a physical center, how would you be able to track student enrollments back to the on-campus sales rep, an online ad, or a free test prep session that the student attended in college? In most cases, business rules are so complicated that they have to be re-engineered based on common sense.

This was exactly where the complexity of the project was. In slicing and dicing the data, in aggregating enrollment, sales, marketing data based by dozens of parameters and decision points, the team approached desired data accuracy one steps at a time on a thousand-step journey. Each step looked like "come up with the business rule" - "code, test, deploy" - "sweep back hundreds of thousand of records" - "check the data for selected records, apply common sense to figure out the ones that are wrong" - "come up with a new branch to the business logic" - "come up with the business rule" - and all the cycle all over again.

Guess now why waterfall did not work? After the initial cycle (this is when the project was supposed to get completed, according to the 7-page MS Project plan), the project was considered a failure and the team decided to work overtime to make it up. Guess what? After three cycles, the team was exhausted, business stakeholders frustrated, the project manager left the company, and more resources were thrown in to save it.  After three more iterations, accuracy of data increased but it was still not 100% and the resources started leaving the project - moving on to other projects. It was obvious that 100% was not possible with the complexity of data and the business model which supported flexibility of the new business model.

"Agile!" - you will say - and you will be right. As the team moved to Agile, flexibility no longer worked against us. With each iteration, we increased accuracy of data. Demos provided visibility to the business of the complexities and the incremental progress. The 100% dedicated team were able to show results and it no longer felt like a never ending journey. There were realistic goals set up to achieve the accuracy of data, agreed upon with the business, and the scope was split into measurable chunks that were delivered one by one within a matter of three months.

The step from waterfall to scrum was complete and the original scope was delivered, however, this was not the end of the journey. This was a living system in maintenance mode. New requests continued to come in, and our sprint planning was becoming hectic. Sometimes, we would not have enough tickets to estimate during our planning session, but with the high volume of incoming requests, the end of sprint became a struggle of business stakeholders: who will get in their ticket first? Kanhan "first come-first served" approach did not work as the priority of requests ranged from a business analyst researched options to company's senior management who needed this data to make decisions on running the business. The team was pulled in different directions, and sprint review sessions were surfacing misunderstanding and misalignment. Cadence was no longer there, but the spirit still stayed. And jointly we came up with a solution - scrumban!

More in Part II.