Wednesday, December 11, 2013
Scrum Master: Role or Title?
Product Owners define product roadmaps, developers write code, testers ensure quality, but what does a Scrum Master do? My thoughts on the topic are in this AgileConnection article:
http://www.agileconnection.com/article/scrummaster-role-or-title
Wednesday, October 16, 2013
Does a Scrum Master bring value to the organization?
Have you ever dealt with a skeptic in your organization who does not think that scrum masters bring value to the team? Who thinks that all that scrum masters should do is schedule and facilitate ceremonies, and everything else that scrum masters do - removing impediments, protecting the team from distractions, improving the process - the members of cross-functional teams would do without any problem. He views scrum masters as creating more work for team members in order to justify their own existence.
I know this is not the case. Without the scrum masters, team members will have to spend hours removing impediments, fighting with external distractions, and implementing improved processes on their teams. However, this is hard to quantify, unless we remove a scrum master from a team and measure their productivity before and after. But if we don't want to be that radical, what can we do?
The more I have been thinking about it and trying to quantify Scrum Master value, the more I realized that the best scrum masters are not those who are highly visible and vocal but those who are most supportive of their teams, who encourage continuous improvement, and make their contribution to the team almost seamless. This is similar to the race car mechanic who's not visible during the race but plays crucial role in the team success.
This thought did not help me with coming up with the proof of the Scrum Master value and an explanation that it won't be right to have team members protect themselves or remove impediments, such as coordination of development and deployment activities with other teams, changing priorities, and changes in team composition. So I posted the question on linkedin forum for certified scrum masters (got several great ideas and a lot of encouragement) and did some research. What I found is fascinating! I truly believe that this is what defines a great Scrum Master:
Tao Te Ching Written by Lao-tzu Ch 17
When the Master governs, the people
are hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst is one who is despised.
If you don't trust the people, you
make them untrustworthy.
The Master doesn't talk, he acts. When
his work is done, the people say,
"Amazing: we did it, all by ourselves!"Credit goes to Jeff O.
While this is so true, it is hard to prove the value of something that is not always visible and never is obvious. To understand the value that scrum master brings to the team, a good starting point is the checklist of things the ScrumMaster can look at and work on. Michael James from Danube has an excellent Scrum Master Checklist available for download. Another great Scrum Master checklist was put together by Bernd Schiffer who cites Scrum Master manifesto in response to a common misconception that Scrum Master is not a full-time job: "We believe the Scrum Master is a full-time position for one person on one Scrum team ."I would argue that the team won't achieve hyperproductivity without a scrum masters described in this checklist whose value is well defined by Bob Hartman. Both Bob Hartman and Michael James speak of intangible things - influence, sense of purpose, commitment - which translate into tangible outcomes which can be measured. Similarly, Len Lagestee speaks of "transformational leadership" - the role that scrum masters play on their teams supporting their path to greatness and about leadership code of a Scrum Master.
This type of value is not easy to quantify. I like comparison of a scrum master with a football coach standing on the side-lines during the game. A football coach doesn’t play a position but they are constantly looking at how the team are interacting with each other. They know if the defensive line is being held too high and how the team aren’t working together to achieve a common vision. After the game the coach helps the team look at their performance for strengths and weaknesses, they’ll identify actions for potential changes and implement them incrementally. Although a football team may be able to play 1 or 2 games without a coach, other teams may eventually overtake them in ability and effectiveness.
So I do not give up. I want to use Michael James' checklilst, testimonials from Scrum Masters and teams to educate the stakeholders on Scrum Master value. We also had a very good Scrum Master Forum discussion where Scrum Masters shared their success stories where something they did moved the needle for their team, removed a significant impediment, or motivated team members. This was a great celebration of Scrum Master value!
Monday, October 7, 2013
Tuesday, April 16, 2013
Agile Events Calendar
My team maintains a calendar of Agile events in New York/New Jersey as well as webinars and other events and training opportunities available to Agile practitioners. Hope you find it useful. Please post any suggestions for improvement as well as any additional events in Comments so that we can benefit from this knowledge sharing opportunities together.
Saturday, April 13, 2013
The Mastery of Lean Startup
The concept of Lean Startup introduced by Erik Ries is an amazing collection of common sense and innovative ideas. If you have not seen his Google talk or read his book on Lean Startup, my advice for you is to stop reading this blog and watch this video instead. My Agile team at work has our own Book Club, and the last three sprints, we are reading Erik Ries' book, and each time we find a lot there to admire, and about as much to disagree with. Some ideas resonate with me (validated learning, minimally viable product, pivoting once your assumptions are invalidated - all makes perfect sense) while selecting a small group of customers to validate your product and make decisions based on this restricted subgroup does not.
I value contradictions. Primarily, I do so because I do not believe that they exist. I treat them as puzzles for us to solve. So when I got a qiestion whether I would want to go to Lean Startup Machine Training in New York, I said "yes" without hesitation, even though I had no clue what the training is going to be. And once I did, I found that it is all-weekend training which starts on Friday evening and ends of a Sunday evening, and goes almost non-stop for all three days. It is a hackathon-like experience for entrepreneurs and for anyone who wants to learn how to start building your product right. The concept of working through the whole week-end slightly scared me but not enough to pass on this exciting opportunity, so I rolled my sleeves, checked into a hotel in New York and started the 3-day marathon.
Now that the second day is over, I want to share my thoughts with you while the experience is still fresh.
First, it is worth doing! Learning about lean startup is nothing compared with going through it. Powered by a simple yet powerful product envisioning tool called validation board, my team started with building a fee-free tool for business professionals who need to find company after work hours while on travel (at that time, we were thinking of social activities or just a friendly chat) and after 5 pivots and a lot of interviews of potential customers, we have designed a VIP Travelers Club with a $5K/year membership fees. Interesting that our first idea had a very low conversion rate while the final one brought us an advisor who wants to introduce us to an investor. You never know your customers until you ask them directly! This is my learning experience #1. And the second one is similar: "go out"," "talk to the people". My two teammates - Hao and David - and I spoke a lot to the strangers and learned that the first product that we loved and voted for has limited business value while the final one has a significant business potential.
Why am I telling your this? - To encourage you to get out of the building, meet your end user, validate your assumptions and pivot as many times as you need until you find a perfect combination for your Minimally Viable Product (MVP). And once you did, validate and build over again. This is how all successful product owners create their winning products.
Sunday, February 10, 2013
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 :-)
Sunday, February 3, 2013
Commitment vs. Forecasting
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)
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.
Subscribe to:
Posts (Atom)