This Sprint Future-O-Spective with Santa Claus!

Here’s the festive season again and Santa Claus is coming to town. We need to take care of the balloons during the party so they shouldn't look awful.

What may be the impediments which need to be taken care?

•       During freezing weather, balloons shrink up terribly
•       Balloons should be retained for longer period of time
•       Safeguard balloons from our pet parrot with curved beak which is keen of pricking balloons

Our futuristic actions-

• We shall use good quality latex balloons
• Coat hi-float* on the balloons
• User Cold helium or nitrogen
• Keep our naughty parrot in the cage till the party gets over.

*Hi-Float: is a gummy resin that you apply to latex balloons to allow them to retain helium for longer periods of time.

Now team can identify how to keep balloons (forthcoming Stories of the project) safe from the identified impediments by effective utilization of resources available, or by acquiring the needed resources.

Special thanks to Bhavin Shah for drawing this wonderful drawing board.

Agile Nuggets: Simplicity!

I have seen many software projects suffering from few common dysfunctions. A few dysfunctions are mentioned below:

• Stakeholders made the things complicated than they need to be
• The real customer requirement was based on a business need and was something very simple but there was a communications gap between business analyst and programmers
• Gluttony -Product Owner
• Gluttony -ScrumMaster
• Gluttony -Development team
• Habit of taking Debts (Technical/Non-technical)
• Tight coupling of features and functions
• 
  

• A few more…

Today let us see the first one- ‘Stakeholders made the things complicated than they need to be.’

A few years back I read a very interesting analogy presented by Scott Davis,U.S. Below are the excerpts I would like to share with readers.

[My microwave oven only has one button: “add a minute.” To boil a cup of water for my coffee, I press the button three times. To melt cheese on my crackers, one click. To warm up a flour tortilla, I press “add a minute” and then open the door after 15 seconds.

Would a one-button microwave oven ever make it out of the planning committee?

Probably not. I can tell by the (never used) features on my microwave that the committee favored complexity over simplicity. Of course, they probably cloaked “complexity” in the euphemism “feature-rich.” No one ever starts out with the goal of making a product that is unnecessarily complex. The complexity comes along accidentally.

Suppose that I have a slice of cold pizza that I want to warm up. According to the manufacturer’s directions, I should press the “menu” button. 

I am now faced with the options “speedcook” or “reheat.” (Um, “reheat,” I guess, although I’m kind of hungry. I wonder if speedcook will be any faster than reheat?) 

“Beverage,” “pasta,” “pizza,” “plate of food,” “sauce,” or “soup”? (I choose “pizza,” although it does have sauce on it, and it is on a plate.)

“Deli/Fresh” or “Frozen”? (Neither, actually—it’s leftover delivery pizza. I’ll choose “Deli/Fresh,” I guess.) “1 slice,” “2 slices,” “3 slices,” or “4 slices”?

I have no idea how much longer this interrogation will last, so I press Cancel and then the “add a minute” button.

Amazon.com only has one button: “one-click purchase.” Oh, sure, I had to type in my address and my credit card number the first time I visited, but now I am one click away from my impulse buy.]

The well-known 80:20 rule in software says that 80% of users only use 20% of features.

• 45% of features were never used;
• 19% used rarely;
• 16% sometimes;
• Only 20% were used frequently or always.

However the focus on making the product “feature-rich” sometime makes it unnecessarily complex. 

The other example of such feature-rich products I see is my Mobile phone. :-) 
I am not sure how many times I used the fascinating features like 'Gesture Recognizer' it offers.

There are many ways Product owner/Stakeholders can decide the priority of the features needed. One of those I have explained in my other post.

We will keep on discussing the other dysfunctions in forthcoming Agile nuggets, stay tuned!

Improvements through Scrum Ceremonies...

We all know Transparency, Inspection and Adaptation are the three pillars of empirical process in Agile development.

Our team works in a transparent way, processes are transparent and even practices are transparent. But how our team inspects and adapts?

Certainly there are well defined processes for Inspect and Adapt.

Daily Scrum: In this 15 minutes timeboxed activity, all the team members inspect progress toward the sprint goal in the form of answers of the three questions provided by each team member of development team.

• What I did since the last daily scrum?
• What I plan to complete by the next daily scrum?
• What are the obstacles or impediments preventing me from making progress? 

Based on the answers team synchronizes and adapts the plan for the work till next Daily Scrum.

Sprint review: Sprint review helps the Scrum team to inspect and adapt the product. During review team gets feedback from various stakeholders and based on that adapts what to do next.

Sprint retrospective: Sprint retrospective helps the team to inspect the processes/practices being followed and adapt accordingly. There may be something to continue, to stop or to start.

Backlog refinement: Generally teams do not count this ceremony as a inspect and adapt activity but I strongly believe that due to this ceremony, Product owner gets chance to prioritize the stories and gets to know the clarifications development team may need during next sprint planning.

So all set with the Inspect and Adapt activities! Now I need few answers from the readers.

•          If any impediment comes after the daily scrum, do we need to wait till the next daily scrum?
•          During development, for example some suggestion comes up during some implementation, should we wait till Sprint review?
•          During sprint if any team member comes across with a very effective open source tool which can save a lot of efforts and time, should he/she wait till the Sprint retrospective? And yes we should bear in mind that some teams follow 4 week sprint.
•          The Product owner senses the heat of the market and wants to add/remove some stories from the backlog, should he wait till next sprint?

You said it right! Inspect and Adapt are not dependent on any ceremonies. And that’s how we achieve “CONTINUOUS IMPROVEMENT” because we do not wait for ceremonies to take place first and then go for any improvement/adaptation.

I know enthusiastic team members want to see their great ideas start working in their sprints as soon as any such idea tickles in their mindJ. But sometimes other team members want to analyse and make sure that the point(s) suggested for improvement is valid/authentic for the team and the work being done. They want to take some time for a quick discussion on that. 

I suggest that the member who got the idea, should make a note, may be write that on a sticky note and place that on the team's board. (Sticky with a different colour works great to grab the attention of the team.) If there are distributed teams, the point can be sent to all for consideration. Team can have a quick discussion on that during some short break and sometime may ask Proof Of Concept from the team member suggesting the point. Once accepted by all, that point can be considered for the sprints as an improvement.

We do not need Product Owner in our Sprint Retrospective...seriously?

Whenever we start a new project there is always a chance of having a few new faces in our scrum development team. Also, there is a big chance of having a new client or at least a new Product Owner in our team. In a nutshell we can say that there is always a possibility of changed team composition when we start a new project. 

The biggest challenge I see (sometimes I embrace it as an opportunity to learn) is, the jelling of new member with the team or the team accepting the new member quickly. And that’s not a big surprise because the reasons are obvious. 

Some of such reasons I experienced are- 
1. Cultural variances 
2. Doubt of efficiently coping up by the new members with the rest of team 
3. Lack of skill sets required to be a Scrum player 
4. New/Immature to Agile culture 
5. … 

Yes, you got it correct! A very effective way to overcome this situation is to break the ice (3Cs…this time a bit different…communicate communicate and communicate) with openness and transparency. 

But surprisingly I have observed that sometimes a few teams tend to miss such opportunities which come in the form of Scrum ceremonies. One of such ceremonies which I experienced that teams try not to include Product Owner is Sprint Retrospective. 

I ask only one question (humbly) to team that let me know a single reason to not inviting Product Owner in Sprint Retrospective. You might think that there would be NO answer. But there always exists at least one. Team- “We would like to discuss this between development team as there are few things we want to discuss and keep within development team”. 

How does this sound? Team wants to keep something hidden from Product Owner? This seems odd. There is something seriously wrong happening with team and certainly a lack of trust and transparency? 

Ok, now you as a ScrumMaster tried to find out the root cause to know what development team wants to hide from Product owner and you find that during planning team over committed and they took some kind of debt (Not necessarily technical debt). Team thinks that it is better to hide this from Product owner and repay it in next sprints. After all development team want to see Happy Product Owner and listen “Bravo!”. 

Cool… So now team will hide this debt from Product owner and will be in a catch 22 situation. Will team repay the Debt or will it keep on increasing? Let us keep finger crossed and watch Spectre with some awesome actions by Daniel Craig :-|. 

On the contrary when you involve Product Owner in your retrospective and update him about the debt team has taken during the sprint and the plan to repay in next/subsequent sprints, there are full chances that your Product owner will understand this and you will get some user story in your backlog. Even if he doesn't appreciate you but one thing he will establish and that is your honesty, that’s the first step you took for trust building. 

And yes, team is tired after the sprint done and everyone needs a break. So there are two chances, either some of the team members will try to escape from retrospective or if they participate for the sake of ceremony then it will be boring and the outcome will be not as expected. So why not mix some fun in your Sprint retrospectives? Play some game (different with the one you played in past) for your retrospective and see the difference.

Don't forget to share your experience with your Funtrospective.

Enhance iterative development with Mikado Method...

Let us start today with Boy Scout rule.

Boy Scout rule says that- “Always leave the camp-ground cleaner than you found it.”

If you find a mess on the ground, you clean it up regardless of who might have made

the mess. You intentionally improve the environment for the next group of campers.

Bob Martin (and others) nicely explained why Boy Scout rule applies to product development

and technical debt (Martin 2008).

And that’s what we follow during software code implementation/development.

Recently I found a very interesting method Mikado Method which is companion to Boy Scout rule. Let us have a high view of Mikado Method. (I might be coming up with more details later!)

Mikado Method is very helpful while repaying Technical Debts. This method is also a very effective way to morph an existing system into a desired new shape. This is, when we try to customise existing system with the client specific modifications. Most of the time it seems to be very simple and less time/efforts consuming but most of the time it turns out to be a nightmare. 

Mikado Method works very well with Extreme Programming, Scrum, and Kanban. It has four simple concepts.

• Set a goal
• This can be in the shape of a user story.
• Experiment
• Make an experiment without analyzing the consequences too much.
• Visualize
• Verify the impediments and find out errors
• Find out the solution to fix the errors/impediments (without over analysis)
• The found solution for fixing the errors will be now the new prerequisites for the goal. This needs to be drawn somewhere, may be on team’s whiteboard.
• Undo
• Revert the code to the initial state where the errors were encountered.
• Fulfill the prerequisites.
• Perform the process of reverting and fulfilling the pre-requisites for all the errors/prerequisites till goal becomes error free.

When goal is error free, Check-in the code. Verify once and Voila! You are done.

(All suggestions are welcome!)

Searching for a New Agile School to learn collaborating with Offshore Teams?

Cultural ignorance and mushrooming Agile schools are creating strange team dynamics

Offshore resources have been an important part of the software development industry and always will be. They have been part of the process since the traditional software development method was starting to blossom. However, in this era, when Agile methods have an edge over traditional ones, offshore development needs more attention and a smoother collaboration among teams.

A few questions to consider:

• Are you a self-proclaimed Agile coach on the verge of opening a new Agile school?
• Do you find it difficult managing or working with distributed teams?
• Do you fear that offshore development is going to result in failure, and you may not be able to control the outcome?
• Are you lucky enough to easily recruit cross-functional professionals with T-shaped skills for any development team that can co-locate?

This article is not for you if you can answer "Yes" to all of the above questions.

Does this sound like you?

• You have worked on Scrum projects for quite some time and found that Scrum fit well in the distributed environment, with good collaboration among Scrum teams.
• You have some knowledge of Scrum of Scrums.
• You do not completely agree with the three Don’ts for the development team (i.e., large, multi-site, and offshore). I overheard these don't in a webinar :-)

This piece is definitely for you if you answered "Yes" to any of the above statements.

The biggest challenge faced during offshore development is the cultural variance. To better understand the implications, let us look at Agile veteran Mike Cohn’s views on cultural variances. In his book Succeeding with Agile: Software Development Using Scrum, Cohn explains well how to work with offshore teams.

Excerpts from the book:
Hofstede identified five key dimensions along which cultures varied.

Power Distance index (PDI) - The extent to which less powerful members of a culture accept that power is unequally distributed.

Individualism (IDV) - The extent to which individuals prefer to function as individuals rather than as part of a group.

Achievement Orientation (ACH) - The extent to which the culture is oriented toward achievement, such as earnings, visible signs of success, and possessions.

Uncertainty Avoidance Index (UAI) - The extent to which the culture is tolerant of uncertainty and ambiguity.

Long-Term Orientation (LTO) - The extent to which the culture favors long-term considerations over immediate physical and financial benefits.

You can use the data in a table like this by finding the row for your country and seeing how your country compares to others on the project. For example, if I were about to start a project with team members in China, I would compare the United States and China rows. I find that China has a much higher PDI score (80 compared to 40 for the United States). This tells me that my Chinese colleagues will be less likely to challenge authority than I am used to. If I am in a role of real or perceived authority (e.g., ScrumMaster or senior developer), I will put extra effort into making sure that team members in China engage me in open discussion.

Looking next at the individualism scores (20 for China, 91 for the United States), I learn that my team members in China will be more interested in team unity than I am used to. They will be less likely to want to be singled out, even for praise.

The excerpt clearly shows different cultural variances and tells us that we need to adopt different approaches to bridge the cultural gap. Although the statistics in the table are outdated and might have changed a bit, globalization and working with Agile teams have already bridged part of the gap. However, more efforts are needed to completely eliminate it.

So the question is: As a product owner or ScrumMaster, why should I choose an offshore team? Below are a few of the reasons:

Reduced cost (for skilled development team or infrastructure)

Easy availability (availability of skilled developers is higher)

Impossibility of always getting cross-functional, T-shaped-skilled people for colocated development teams

To be Agile and collaborative, and to understand cultural variance, each product owner or ScrumMaster must come out of his or her comfort zone. After all, success depends on all three pillars: transparency, inspection, and adaptation.

In addition, a positive attitude works wonders. Try it!

"Keep your face towards the sunshine and shadows will fall behind you." -- Walt Whitman 

Non Violent Communication and Emotions during sprints

A few weeks back I attended a session on ‘Non Violent Communication’ delivered by one of my colleagues in my organization. The session was extraordinary and was something in line with what I always make as a point while guiding agile teams. (Special thanks to Adam for the session!)

This session led me to relate the emotions and the Non Violent Communication of team members and the combined impact on the day to day team activities. Before moving forward, let us see what veteran agile coach Lyssa Adkin says for emotions.

Lyssa says in her book- Coaching Agile Teams, -‘We practice mastering ourselves in the moment so that we can better open ourselves to being a servant leader and to harness our emotions and choose what to do with our reactions. Yet we’re human. We react.’

Lyssa further explains-‘Sometimes, the team needs you to remain unfiltered—to see your reaction as a reflection of what just happened. More often, though, your reaction is about you and has no place in the coaching. Notice your reaction and consciously choose whether to act on it. This is the practiced skill.’

So this gives Agile coaches a sense of their emotional state. Now I come to emotional state of team members. Emotions play a vital role, for ScrumMaster/Facilitator and for agile team members as well. When I say about emotional state of team members, it may be individual’s emotions or team’s emotions collectively depending upon the situations.

Emotions can be reflected directly or indirectly. There are many factors which controls emotions. For example- Matter being discussed, Religious beliefs, Cultural differences etc and most importantly communication (if not following the Non Violent Communication). If an agile team is not adopting Non Violent Communication, sometimes team members get hurt by the way communications take place. Violent communications not only demotivate people but also hinder transparency and collaboration. This creates problem for smooth functioning of a team.  A good emotional state of individuals creates a positive impact on team’s deliveries (sprint). 

To control impact of emotions on day to day life is not an easy task and when it comes to team’s emotion, a facilitator cannot steer it however he or she could help to understand the reasons effecting the emotions. If there are some points which could be taken-care by facilitator to refrain negative emotions, he/she can make efforts to control it. Sometimes people just need to know that their concerns have been heard. However as I stated, it is not so easy task and needs a careful effort otherwise can lead to more complications.

Each ceremony of scrum reflects emotional state of team yet Sprint Retrospective is the ceremony where team can look back to whole sprint and share their emotions during that sprint. These are the emotions which drive what went good, what went wrong and what needs to be improved. So facilitator must focus on understanding these emotions. If needed the results of retrospectives may be forwarded to Enterprise Transition team/Project Management Office.

One important aspect of getting true value out of Sprint Retrospectives is the games being played in Retrospectives. I have seen many teams which do not invest time in such games and sometimes lead to dry and monotonous retrospectives. In my next piece, I will come with such games which make the retrospectives livelier. Till then keep me posting your views on EMOTIONS.

Fix bid (Agile) project. Are you ready?

What is a fix bid (Agile) project?

This is a general understanding that fix bid project means fix price, fix time, fix scope and obviously with quality. This requires detailed and accurate requirements. ‘The IRON TRIANGLE’…

However a ‘Fix bid AGILE project’ is bit different from the above understanding. How? We will see it in the later part.

Now let us understand why customers ask for fix bid project?

·         Many customers do not have significant idea, what agile means. They think that from an agile project they will get iterative deliveries hence more control on project and less surprises at later stages.

·         Customers do not want to take any financial risk.

·         Customers (generally government institutions) need to choose between bids. They have to stick with fix bid project which also needs to be agile.

·         Lack of trust between Clients and Contractor. And this is obvious as every time the projects are not from the same clients or from the clients which know enough about contractor prior to the project.

What benefits a contractor may anticipate from fix bid project?

Not all the time but at times contractor also gets benefited from fix bid agile projects.

·         A contractor can predict his cost and benefits.

·         Planning in a fixed price project is easier. As cost and benefits are predicted in advance, the other planning as scheduling and resourcing becomes easier. Contractor can focus on other projects easily as fix bid projects scope and timelines also are fixed.

·         Generally this happens when the domain is well known to contractor. If the contractor is selling its product then the expertise is already with contractor. Say, if we are selling our own product (company’s product) then we already have enough expertise and SMEs with us. We know almost all features/functions in advance. Yes, there may be a few customization needed as per the client’s requirement. If planned well, we can go ahead with fix bid agile projects.

What should be the way of collaboration between client and contractor?

·         First of all client should know what Agile means and how an agile project will be developed and delivered.

·         Preferably a Product owner from client should be available, if not, contractor may provide agile training to a SME (Subject Matter Expert) - a representative from client. If this is not possible, offer client a proxy Product owner.

Fix bid AGILE project

In most of the cases client is more focused on TIME (Deadlines) and BUDGET. So the only option left flexible is SCOPE. Though clients forces for fix SCOPE also but in Agile project the scope is drilled down from VISION to Stories (even more up to tasks). So once we discuss about the scope, we could provide client a range of Stories expected to be covered in the Fix Time and Fix Budget. Sometimes stories may still be in form of EPIC (Big story).

It had been debated many times that Product owner from client asks for inclusion of more and more stories in sprints. In such cases ScrumMater and the team can guide Product owner about the team’s capacity. In my opinion if the team (Product owner, ScrumMaster, Development team) is working in collaboration such things could be tackled easily. After all Product owner also works for success of product/project and he/she responsible for the same. :-)

How to deal with Change requests

Change is inevitable. Agile welcomes Changes and that is the essence of Agile. However in Fix bid it creates confusion.  Change is inevitable but BUDGET is fix :-).

The best way to deal with Change request is to drop comparatively less important user stories (equal story points which the change request have). Having fix bid project, it becomes tough to convince clients. If you could do that, go-ahead, get some more bucks from client.

More on how to judge importance of a user story can be found at:

https://www.scrumalliance.org/community/articles/2015/january/product-backlog-refinement-and-prioritization-with

The Monster of Cross-Functional Scrum Teams

The question here is- Are we using the right environment to create teams with cross-functional, T-shaped skills?

We see many instances in new Scrum teams in which team members don't work on skill sets other than their own core skills. I have heard such concerns from many ScrumMasters. This is a situation where you will find that it is not easy to create a cross-functional development team with a T-shaped skill set.

If we inspect closely, there are many reasons behind this unwillingness from team members, which need to be addressed prior to attempting the creation of a cross-functional, T-shaped development team.

Let us imagine what the scenarios might have been when you tried this experiment with your team:

• Hey Bob, could you do testing along with Chris, as Maria will be on leave for the next four days?
• Trisia! You're leaving us by next month and Mak will be on this project, and it would be great if you could help David in executing the test cases.
• Brad, you have worked very well in this .net MVC project, but the integration part in php is not doing well. Because you've previously worked in php also, can you please start looking into that? You may devote 60 percent of your time in that module.
• Hey Paul, please work on data migration till other functional requirements are ready to be discussed.

There may be a lot of other scenarios within teams you worked on or might have seen in other teams. (Please add your thoughts in the comment section below.)

What do you think went wrong in scenarios above?

Generally in newly formed teams, we ask a developer for help when someone with that skill set is not available or when it is discovered, at an advanced stage, that more help is needed to complete the sprint tasks. Usually this leads to stretching working hours. I have generally found that in newly formed teams, it works adversely to burden someone in pretext of asking for his or her help.

Sometimes a developer doesn't bring up the fact that he or she doesn't have adequate skills in a required area. Hence it makes sense to indicate that appropriate training will be provided prior to assigning him or her such tasks. Also, we need to assure these developers that their core skills will always be considered when assigning tasks. In mature teams, we rely on task "pulling," but initially in new teams it's task "pushing" in the forming stage.

There is always a fear that working on a different skill set will lead to work on other skills only, and no longer on core skills, especially if there's a scarcity of experience on the team with that needed skill set. However, developers should not have to fear that they'll be spending most of their time on the "other" skill set at the expense of their core skills. This can hamper their ongoing improvement in their core skill set and prove demoralizing.

Often such situations lead to job hopping instead of creating cross-functional teams.

See more at: https://www.scrumalliance.org/community/articles/2015/march/monster-of-cross-functional-teams

Similarities in cycling and practicing Scrum.

I remember when I first tried riding a bicycle. It was my elder brother’s red colored bicycle. Its color always fascinated me. One day I requested him to allow me to take its ride. First he had a hitch to allow me as he was worried of three things,

•         What if I fell down and get hurt?
•       What if I get hurt and blame goes to him? (For kids this is the most critical moment to face the parentsJ…forget about the wounds!)
•         What if his bicycle gets damage?

But later when I repeatedly requested him, he agreed with barter of some portion of my pocket money and we planned that on next weekend we would go to nearby ground where he will help me to learn riding bicycle.

The D-day came and my elder brother gave me a few instructions such as, how to make balance on bicycle, how to apply brakes, …etc. He kept running behind the bicycle and hold it to prevent me falling down and help me keeping balance while I was riding and after a few such attempts, I learned balancing bicycle!

No lengthy procedures, no lot of rules (I am not referring the traffic rules), no instruction-booklets. It was simple. My brother was my guide, a few rules of cycling as balancing, applying brakes, driving on right side of the ground (road). That’s it!

Why I mentioned it here? Reason is – Practising Scrum is same as riding a bike. No lengthy procedures, no lot of rules, no heavy documentation. If you will keep on planning, you are only going to delay learning Scrum. You need to put Scrum in practice.

The only things needed are:

• A determination for adapting scrum
• Understanding a very few ceremonies (Sprint planning, Backlog refinement, Daily Scrum, Sprint review, Scrum Retrospective)
• Yes, there is a need of one scrum coach during initial weeks and voila! You are scrummified, your team is scrummified.

So what you are waiting for? Go get scrummified.

Hold on Scrum Players, Your Team Still Needs Clarity on Some Game Rules!

Different opinions among Scrum followers sometimes create points of discussion. Recently one such point was, "Who can terminate a sprint?" There were three different opinions, covering all three roles in Scrum (ScrumMaster, product owner, development team). Below are excerpts from Scrum experts that give us insight into the different answers to this question.

In Agile Project Management with Scrum, Ken Schwaber says, "If the Sprint proves to be not viable, the ScrumMaster can abnormally terminate the Sprint and initiate a new Sprint planning meeting to initiate the next Sprint. The ScrumMaster can make this change of his or her own accord or as requested by the Team or the Product Owner."

Kenneth Rubin, in Essential Scrum, writes, "Should the sprint goal become completely invalid, the Scrum team may decide that continuing with the current sprint makes no sense and advise the product owner to abnormally terminate the sprint."

And in Succeeding with Agile, Mike Cohn writes, "Let's consider the case of the product owner discovering some important new requirement that she says needs to be done instead of the work the team is engaged in. Sometimes this will happen. When it does I suggest making the change in sprint goal visible. Scrum does this by having the team announce an abnormal termination to the sprint . . . "

What I want to make clear here, as is made clear in the quotes above, is the importance of context. Without understanding the context of the situation, one should not get carried away with one's own opinion. One must consider the scenario leading to the termination of the sprint. Though sprint termination is rare, sometimes compelling reasons indicate its need. Whatever the case is, due to transparency in Scrum practices, reasons will be visible to all. The Scrum team has to act according to the situation. Sprint termination is not a decision taken without the consensus of the team, and the Scrum team is comprised of all three roles: product owner + ScrumMaster + development team.

Originally published at: https://www.scrumalliance.org/community/articles/2015/february/hold-on-scrum-players-your-team-still-need-clarity

Who Am I?

I am Waterfall. You must have read a lot about me and have probably used or may still be using my method in your projects. I have lived a very fascinating life. I and my followers have tasted success in most projects with my well-defined processes. Sometimes there have been failures and slippages during deliveries. . . . OK, OK, I admit that many times there were slippages. But it was neither my fault nor that of my processes. Even the people involved were following the processes well. Everything was in place. The whole blame goes to the clients, as they never stuck to the initially defined requirements and kept on asking for changes, even in the advanced stages when such changes were too expensive. And the most daunting thing was that the demand for these changes was always urgent.

I sometimes see that teams are in the process of making plans for the requested changes and are near to finishing detailed documents, and suddenly clients change their minds and come up with new changes/functionalities. Even worse situations happen when products go for user acceptance and they find that the functionalities incorporated are not as intended.

Furthermore, the complexity of projects is at a peak these days. There was a time when clients were patient enough to wait for products. They used to provide each and every small detail, and based on that we prepared precise documents and contracts. But now every client wants early ROI (return on investment) and every requirement is urgent, due to competitiveness in the market.

Nonetheless, things were working by and large -- until I met my cousin, Agile.

She is younger than I and seems very dynamic. I came to know that she also has a few frameworks/methods -- Scrum, XP, BDD, TDD. She advocates iterative deliveries with the collaboration of customers/clients. I thought I should analyze those Agile methods to find out why they were going viral.

Very soon I encountered Scrum. He has some weird activities, such as the Daily Scrum, sprints, review and retro, backlogs, etc. I started comparing these ceremonies with my practices, and I found that most of my followers were doing such activities as and when required. However, the significant difference was the timeboxing.

Then I remembered the "Cone of Uncertainty" in software development.



The "Cone of Uncertainty" graph was initially discussed by Barry Boehm (Boehm, 1981) and later called the Cone of Uncertainty by Steve McConnell (Mc Connell, 1997).
And to my surprise, the uncertainty is being handled very well in Agile/Scrum. The reason is those small sprints and fail-fast strategies. The fail-fast strategy means trying some task, getting quick feedback, and then inspecting and adapting as per the feedback received.

I started liking these small yet effective measures. But I still had one more thing to consider. The Iron Triangle. . . .



I always give the example of the Iron Triangle. And this is the fact, that one has to keep a balance among scope, schedule, and resources while maintaining quality. How was Scrum was handling that? What I found was that Scrum also maintains the triangle but has some flexibility. If clients choose the fix date, Scrum accommodates only those features that are feasible to deliver by that date, keeping a focus on prioritized features. And if scope is fixed, then the schedule is planned accordingly. The most striking part is the involvement of the client/product owner from start to finish during product delivery.

Scrum also has a Manifesto for Agile Software Development:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

There were a lot of other such practices in Scrum that amazed me. I felt transformed by this upstart project development practice. I felt energized. And why not? I and my cousin were both from the same family -- Project Management -- and the sole purpose of my existence was to help the people managing projects.

I advised my followers to learn to apply Agile practices, to embrace agility for organizational change. There were a few questions from a few managers about their existence. They feared losing control of team management. They were concerned about their role in self-organized teams. And certainly their questions needed to be answered to mitigate their anxieties.

This was quite challenging to me, guiding them toward agility. But I was determined, so I explained them the following:

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is. -- Philip Anderson, The Biology of Business

Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. -- Takeuchi and Nonaka, "The New New Product Development Game"

So do you think that I got defeated by my cousin Agile? No, I have not been defeated. I have given way to Agile for advancement of project management as per the current fluctuating and complex projects. I will still exist by transforming myself according to the specific needs of organizations. Many of my good practices can be blended with Agile/Lean/other practices.

The word water in my name reveals that I can change my shape per the needed vessel. If you are using my method, you still can tailor me by blending agility as per your specific needs and moving further toward agility.

Who am I? I am Waterfall. . . .

 Originally appeared at: https://www.scrumalliance.org/community/articles/2015/january/who-am-i-a-biography

Product Backlog Refinement and Prioritization with the Help of the Kano Model

Tremendous fluctuations in requirements, the heat of the market, competitiveness -- these are a few factors that arise during product development and force stakeholders to keep a continuous watch on the market and ask for quick changes as and when required. The Kano model helps Scrum product owners during product backlog refinement, in light of such changes and demands.

In Scrum, we welcome feedback and change requests from stakeholders, but it is important for a product owner to categorize and prioritize both change requests and the demand for inclusion of new features. At times the requests are just fancy tasks and do not contribute much value to business; hence they may be taken up later or could be discarded. On the other hand, some complex tasks provide good value to business and hence need to be taken up immediately. To get a grip on the flow of such requirements, the product owner needs to identify customer needs, analyze competitive products, analyze the value of such features, and -- based on all of that -- prioritize the product backlog items.

The Kano Model of Customer Satisfaction divides product attributes into three categories:

1. Threshold attributes
2. Performance attributes
3. Excitement attributes

If any product might be competitive in the market, then it must meet all threshold attributes (must-have features), performance attributes (should-have features), and excitement attributes (good-to-have features with value for business).

Let us take an example of a mobile phone.

Threshold attributes would be the ability to make outgoing calls and receive incoming calls, inclusion of a built-in camera, etc.

Performance attributes would be long battery life, a strong body, etc.

Excitement attributes would be assistive light, navigator apps, etc. These excitement attributes increase customer satisfaction, but their absence does not lead to dissatisfaction.

A challenge for a product owner is to manage the flow of multiple requirements coming from stakeholders and bring everyone to consensus about the requirements that provide the greatest value to business.

There are many approaches to limit the flow of requirements. A simple approach that's helpful for prioritizing the product backlog items is to ask stakeholders two simple questions for each attribute:

• Can you rate your satisfaction level, assuming the product has this attribute?
• Can you rate your dissatisfaction level, assuming the product does not have this attribute?

Use a scale of 0 to 10 for both questions. Tally the answers provided by stakeholders for each attribute. The result will help the product owner reach a conclusion. If, for each question, the counts fluctuate a great deal, the product owner can use Planning Poker to get a more exact count for each attribute/requirement and help all stakeholders come to consensus on that.

If you have more suggestions for product owners to help them manage and effectively prioritize the flow of requirements, please share your ideas

Originally published at Scrum Alliance web site- https://www.scrumalliance.org/community/articles/2015/january/product-backlog-refinement-and-prioritization-with

Invent...but do not re-invent the Wheel!

I would like to start with the old saying, "Don't reinvent the wheel." And really, it is an important message! When the wheel was invented, it was made of a simple wooden log. The requirement increased and gradually there were many value additions, such as spokes, rims, tires, alloy wheels, tubeless tires, etc. And that's what we do at our workplace on regular basis: put value additions onto our work.

For example, we use the same libraries already used by thousands of programmers earlier, but we extend these, make some tweaks for specific requirements as and when needed. Hearing this, I know some of us smiled and murmured, "Inheritance?"

Recently I had a talk with a group of IT professionals. I was trying to understand their views on agility and especially on Scrum. (Being a big proponent of Scrum, I love to get involved in such discussions and guide people toward the benefits of Agile and Scrum -- benefits they are not always aware of.) To my surprise, they straightaway remarked that Scrum was not going to help them produce their product. They had already discussed this extensively with other Scrum practitioners.

Later I came to know that their product was reported with many defects, most of them due to not understanding the requirements correctly -- and of course there were a few change requests as well. The product was out, and till the existing defects were resolved there was no plan for next releases. So do you think that coaching them on Scrum was the right step, when there was a sheer need to deal with the current situation? The alternative Agile approach to suggest to them was Kanban. I discussed the way they were handling things and proposed that they follow Kanban principles of visualizing, limiting the work in progress, and managing the flow. They tried Kanban and, as expected, it worked well. Kanban helped them manage the work flow fantastically. And now they were interested in discussing Scrum for their next release. There are still lots of challenges to face, but at least the start has been made, and made well.

This was one such case. The big misconception about Scrum is that it is a tool that can develop products rapidly, inexpensively, and with quality. No! Scrum is not such a tool. Scrum is a framework that helps teams work differently, think differently, and develop products with the goal of the satisfaction of all involved. There are no hard rules in Scrum to follow, and there can't be. Product development is too complex for a single set of rules to fit in all circumstances. Scrum is a proven framework that suits most domains and most situations. To experiment with and enjoy Scrum, you have to identify the requirements of your organization and, if required, tailor the Scrum practices to suit those requirements, while ensuring that the essence of Scrum does not get vaporized. As a next step, your tailored Scrum may lead to Lean Agile practices for your organization. Enjoy it!

Pros and Cons of Modification in Scrum Ceremonies...

Agility is not a new phenomenon. It has evolved with time, the sincere efforts of the Agile community, and its great proponents. Scrum, an Agile framework, achieved popularity with its high number of success results. Development teams started transforming as Scrum teams and a new servant-leader "ScrumMaster" emerged. For the past few years, Scrum has attained wide recognition, and even those organizations that initially overlooked its benefits are now transforming to adopt it. Due to the high success rate of Scrum-led projects and the increased requirements for ScrumMasters and Scrum product owners, many professionals have embraced these roles cheerfully. However, in the enthusiasm a few (wrongly) modified processes are being practiced in many organizations, which sometimes results in failure and stepping into non-Agile methods and myths. I appreciate the efforts people are making to adopt agility while molding some practices to better suit their organizations, but one should take a few preventive measures and inspect such modifications before implementation. This is important not only for new teams but also for matured teams that experiment with such practices and sometimes face adverse results. By saying this, I do not intend to say that we should not experiment! Scrum itself provides room for some calculated modifications. However, before applying such modifications, pros and cons must be considered. I have coached many teams and faced challenges of this type. I have had to implement good practices in some existing teams. The most common behaviors I observed that needed to be changed were as follows: Modifying the names of the ceremonies Not timeboxing ceremonies Treating programmers and testers differently Implementing Scrum without inspecting and understanding the current state of the existing project Modifying the names of ceremonies I found strange names given to a few ceremonies and observed ill effects. For example:

Daily Scrum -- Daily stand-up, daily Scrum meeting, daily status meeting (the worst name)
Sprint review -- Sprint demo meeting

There are two main disadvantages of such renaming. First, not having a common name across the globe leads to misunderstandings. 

"What's in a name? That which we call a rose by any other name would smell as sweet." Great lines by William Shakespeare (Romeo and Juliet)! But in software development, such renaming causes confusion. For example, we cannot call the sprint review a sprint demo or some other name. Even if renaming works within the organization, the rest of the world will be baffled. The second disadvantage is that most names have some significance; using other names ruins that. Calling the Daily Scrum a daily status meeting is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance. In our teams, we made a rule to follow the proper name of the ceremonies to keep everyone synchronized. The same way the sprint review was named a sprint demo; the sole purpose of this ceremony was to demonstrate completed stories/tasks. The teammate who had coded the particular piece of function was responsible for demonstrating it to stakeholders, and other developers were not highly attentive during that demo. It was important to realize that the demo was not only for stakeholders; it was for the whole team. We guided the team to understand the significance of the sprint review and provide the transparent current status to stakeholders. It took time, but providing various examples rejuvenated the team. There are a few other names that need a common tag. For example, "acceptance criteria" and "condition of satisfaction" are the same. Scrum experts are making efforts at this. For example, "product backlog grooming" is now often called "product backlog refinement." Many more are yet to come. Not timeboxing ceremonies This can be challenging -- and linked to modified names. In working with one team, I found that the Daily Scrum was being called a status meeting, and it was not occurring daily. Due to different time zones among the distributed teams, it was held on alternate days and for longer durations. The team was providing the status of the past two days' activities. All teammates sat and provided their status, one by one. The activity descriptions were monotonous and the energy was very low. Further, I observed that the development team found this meeting time-consuming and of no use. We first timeboxed it and limited the questions/answers. (Two additional questions had crept in: "What did we do the day before yesterday?" and "What will we do the day after tomorrow?") We succeeded in convincing everyone that the Daily Scrum should indeed be held daily and that the three original questions would be discussed. The another problem, of answering these three questions while facing and essentially speaking only to the ScrumMaster in a status report, was solved by guiding the team toward the essence of this meeting and positioning the ScrumMaster behind the team, which stood in a half circle. To revitalize the team's energy and sense of cohesion, we introduced new Scrum games. One such game that I introduced is one that calls on everyone's imagination. Please refer my post 'A game of Imagination'.

Treating programmers and testers differently Treating programmers and testers differently is a very dangerous practice and definitely leads to failure. In such situations, programmers and testers do not focus on the target and instead try to find each others' mistakes. In our development team, we called everyone a developer and focused on achieving the goal on time. This helped us avoid unwanted slippage on tasks. For team bonding, I experimented with many varieties of the above-mentioned game and succeeded in achieving excellent team bonding. Implementing Scrum without inspecting and understanding the current state of the existing project This problem, which I observed strongly in a particular team, is certainly common among many new Scrum proponents. Scrum can be used with all projects but is not highly useful in certain situations. For one of the teams that had recently delivered a product with many critical defects, implementing Scrum was not a good idea. The requirement was to immediately provide needed solutions and keep to the task in hand (limit the Work In Progress). We finally got that situation under control by providing the immediate defect resolutions, and then we started following Kanban for support activities. 

Finally . . .

Now each of our teams follows the Boy Scout rule (always leave the campground cleaner than you found it). Whenever we find a process derailing, we gather and discuss it and get it back in place. If you too have faced any such derailed processes, please share your experience, along with the resolution you and your team took.