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.

Agile Ethics

Agile started as a discussion of lightweight software development methods. At least, this is why in February 2001, 17 software developers met at the Snowbird, Utah resort. When I talk to people about what attracts them to Agile, I frequently hear that simplicity of approach resonates with them. Remove unnecessary complexities and waste, and do whatever is meaningful and productive, in a way that works now and here. That is beautiful.

This is not what attracted me to Agile as a concept though. I was fascinated by a simple fact that those people were talking about efficient ways of writing code, and yet they started with values. This did resonate with me. Developing machine code and thinking values – as counter intuitive as it may seem and as organic as it can possibly be.

I have been thinking about the value of having values recently. Specifically,  starting last week. I am trying to comprehend the concept of “prioritizing values”. How can you prioritize values? It’s either a value and then it is a priority, or it’s not, and then, there is no need to prioritize anything. Have you heard of work/life balance?  “I have my values but I am doing whatever is best for my family.” Does it mean I can lie or I can betray someone’s trust if I think this is best for my family? This puzzles me and yet, as a Coach, I hear it sometimes.

Throughout years, I’ve learned to understand the concept of “work/life” balance and yet I do not get it. When I am talking to my colleague or helping my son do his homework, am I a different person? Do I divide “me-at work” and “me-at home”? Do I have different values depending on where I am and what I do? Do I feel happy in a different way when my code finally compiled, or when an employee got a chance he has been waiting for, or when my son does subtraction without counting physical objects? Am I working when I write my Agile blog at 2 am in the morning or am I actually relaxing because I enjoy doing it? I think that the concept of “work/life” is made up by unhappy people who think that when work ends, life starts. Luckily, not so for many of us.

Going back to ethics. When I was a child, ethics for me was no different than etiquette. I associated ethics with eating with the right fork and it seemed to me just another unnecessary constraint humans establish to add unnecessary complexity to their lives. As a child, I implemented a lightweight process of eating everything with a spoon. Worked for me.

When I learned that ethics is a set of moral principles, the concept seemed even duller. Until a week ago when I finally understood why Agile is more than a framework for me. What resonates with me that these 17 people in Utah came up with the principles based on their beliefs. They did not think in terms of “work/life balance” or “I hate to do this to my team but I have to do whatever is best for my family”, they thought about what matters most and based their principles on the values they believe in. This is what ethics is for me. It’s our beliefs in what is right and what is wrong. And right for my team and right for my family are not in conflict. Just because there is one right, and it is the choice that I make.

 I believe that it is not material that the product of this Utah gathering was the Agile framework of software development. If this group of people were in aviation, they would envision an amazing plane which will fly faster than any other comparable plane. If it were an economics theory, it would explain many processes in the modern world that we are still trying to comprehend.

No matter what the area of knowledge is – right values create meaningful things, and this is what Agile is for me. Meaningful approach based on firm beliefs in right or wrong that resonate with me. And I find it hard to believe in “what is best for my family” concept because our values do not change when we come home from work. Otherwise Utah gathering would never happen.

Workplace 2020

 

I do not believe in coincidences. Actually, I do. I just think that most coincidences only seem to be such. Each time I am amazed by a coincidence and start thinking about it, I manage to figure out the reason for it. Here’s a recent example. I read a book about 2020 Workplace and listened to a presentation by Agile coaches at Spotify at NYC Scrum.  There were multiple great points in each, but two parallel thoughts fascinated me.

The book described the onboarding process in a 2020 company. A new employee joins the company. Actually, it is not exactly a new employee because she has been coached by the company and introduced to its business since middle school. But today, during the first day of her employment, she is having virtual meetings with three potential managers who share their vision and suggest work responsibilities to her, hoping that she will select each of them as a manager. And she is responsibly taking the challenge of finding the one whose vision and passion to the work resonates with her. And once she chooses this manager, she will rotate throughout the company during the first year of her employment growing to know the business and people until the chooses where she'd like to work.

The presentation from Spotify coaches was staged as an onboarding process where all participants had to imagine that it’s our first day with the company, and the coaches are telling us a compelling story of company’s values, structure, opportunities, and innovative ways to engage employees. They were not talking about Agile principles, rules, ceremonies. They were talking about the spirit, the “guilds” that promote employee collaboration based on their interests, about support within domain-based "chapters", the unity of "tribes", the ease of choosing and moving to a team, and freedom in selecting practices that work for a team.

I was talking to product owner today about killing team’s motivation with constantly changing priorities, about demotivating them by not releasing their work into production and by not sharing any actual impact of their work with them. And the product owner told me he has nothing to do with it because he has no choice. He depends on his manager, and his manager depends on his bonus. Plain Maslow's hierarchy of needs. No choice here.

All of a sudden it struck me what I liked in the book and the presentation above and what I do not understand in this product owner’s reasoning. 

In the book and in the presentation, the freedom of choice is as organic as ability to breathe. This is what makes us people, this is what motivates us and makes our lives meaningful. World literature is based on the dilemma whether we have choice over our destiny, or our lives are pre-determined by an outside power or environment we're in, whichever it may be. 

In order for our professional life to be meaningful, we want to be able to make our choices, good or bad – but those will be the choices we made. Not the product owner, not the circumstances, not even ROI – we want to work on things that are meaningful, on things that matter to us, and do so with the people we trust who motivate and inspire us. And we want to be able to make a choice.

This is what my responsibility as an Agile coach is: to ensure that teams have choice in making their professional life meaningful and their work emotionally rewarding. I just wish I could find better words in sharing my vision with the product owner. I am not giving up though. Not until his team is giving him another chance. I’ll buy him “The 2020 Workplace” for Christmas. Or Daniel Pink’s “Drive”. Or share Henrik Kniberg’s 15-minute speech about the essence of Agile. I am not giving up on him – he deserves having a choice, too.

My NYC Agile Day 2012 Observations, or IT is All About Simplicity

On September 20, 2012, Ilio Krumins-Beens and I co-presented at Agile Day NYC. It was a wonderful energizing event with several hundred participants from all over the world masterfully organized by Joe Krebs and the team.  I was excited to meet Harrison Owen, inventor of Open Space, who presented at a self-organization track and also participated in the Open Space next day. I was excited to meet Dave Thomas. I follow Dave on twitter and always enjoy hearing his perspective, whether he talks about lean principles or  suggests to retire object oriented programming. Dave is always mind provoking, never boring. Another topic of interest was a participatory workshop of advanced social games led by Stanley Pollack who uses these games with NYC youth to promote friendship and overcome violence. And of course, it was exciting to present and to hear feedback from the participants.

All the presentations I listened to were outstanding. I attended keynote by David Thomas who spoke about a number of topics he is passionate about: lean, OOO principles, requirement elicitation, customer experience. However, throughout all his speech there was one major thought: seek simplicity, do not try to over-engineer - neither the process, nor the technology. According to Dave, OOP is unnecessarily complex, why can’t you use a flat data file or Atom feed? Why would you try to create a 1000-page requirements document if the users in a neighboring department have already automated functionality using excel spreadsheet? Open your eyes, look around. Be simple. Simplicity is organic. It is natural. That’s what we all should be looking for.

Surprisingly, this was the note of Harrison Owen’s presentation at self-organizing track, too. We, human beings, try to plan and control. We create meetings with long agendas and fail answering questions. What is the natural way for a meeting? Invite those who’d like to contribute, those who are passionate, those who are interested, and if they exist, they will come. Don’t bother bringing in others because they will not add value, they will only demotivate the ones you are actually looking for. Bring in those who WANT to contribute. Don’t answer, ask questions. 

The following day, at Open Space, Douglas from American Express asked Joe Krebs and me a beautiful question: “would they come if …?” Would they do it (whatever it is) if they were not paid for doing it? Would they treat you with such a high respect if you were not their manager? Would they work as hard if they did not expect a reward? 

Eva told me that Ilio’s and mine presentation stood out among others. I was surprised because it was a day of excellent presentations and asked why. The answer was “because you are not professional speakers. Because you speak from your heart and it shows.” Isn’t that the power of simplicity? Talk about something you care about in the way that you feel about it. Nothing more simple that that. Thank you, Eva, for this simple and yet so profound thought.

And finally, at a games session, Stanley Pollack taught us how to unleash the way we feel and not be afraid to show it. After five minutes of the “tossing bag” game where I was blocking the flow of throwing the bags which were falling all around me, Staley and Heang asked us what we felt about the team members. When throwing and catching bags, all I could think of not dropping them, but once asked the right question, I said that I think Marco who threw bags to me paused to let me catch up at the expense of having Maria (who was throwing bags to him) being upset to him for failing to catch, and I found that Marco very thoughtful. In addition, Monica who was getting the bags from me, never showed any disappointment that I started throwing her pairs of bags trying to catch up, and after couple of attempts became very skillful in this role. I liked that she did not show me disapproval nor gave up despite having to get a few bags from the floor. Just a few minutes spent with a group of people I’ve never met before, several brief conversations, couple of games, and there is one thing I know for sure: I want to be on a team with Marco and Monica. No complex interviews, no tests designed by psychologists, just a simple workshop, and in the end, I know who I am compatible with professionally and psychologically. We humans are complex systems, no question, but the way we feel, think, change, self-organize, is actually very simple. Because simplicity is organic for us despite all our attempts to create complex rules and regulations. Same thought again.

When I was leaving the Open Space next day, Mary Pratt told me something that perfectly concluded these two amazing days. She  reminded Ambika and me that Agile evolved from something that was called “lightweight software development methods”. No wonder simplicity was my tune throughout two NYC Agile Days. 

Thank you, Joe, Ilio, Heather, Dave, Mary, Monica, Ambika, Marco, Douglas, Harrison, Stanley, Heang, and many old and new friends that I met at Agile NYC Day and the Open Space. We share interest in Agile, desire to learn, and passion of sharing. What can be more simple than that?

Agile Certifications

Further to my previous post on PMI-ACP, below is a link to my prezi.com list of Agile and other relevant certifications:
http://prezi.com/_7xp7tjkhczo/agile-certifications/

The most important point about taking certification for me is the cause. If the cause is to get a promotion, this may have some immediate motivation for some, but they rarely succeed. If the cause is to be better contributor to the team, it is a good cause and this individual has more chances at passing certification exam.

In terms of which certification is better, it is more about you personally. Who are you - scrum master or you have project management background? Are you on a scrum team or you use a different Agile framework? What certifications you already have? What is your primary role on the team? Add this information to your professional desires and beliefs and do not worry which certification is more prestigious. It is all about what is right for you!