Tag Archives: Scrum

Super Heroes

Super Heroes

In a Scrum practicing team, every one is a hero, trying to promise and perform what or what ever it takes to deliver in the Sprint. For transformation projects, the biggest threats are with the super hero’s in the team.

A had a candidate in my team who works like a geek, he understood Scrum, he even takes it to the next level to make his associates understand what Scrum as a framework is?, he works best or bets his velocity, each time. He delivers what is required and sometime more than what is required, He helps associates to complete their work, sometimes working overtime or helping them code or test, or even do their work as his and claim that they have done it. Infact he solves all his impediments by himself. Did I say, he solves it by himself? Well, did you see the hidden threats that can blow up the team even it can delivery Sprints.

What was the candidate trying to do? He was basically doing the whole project by himself. There were physical teams depending on him to deliver for the sprint. The Scrum Master became dumb to understand how unwell the Sprint executed and the threat never showed up even in the Sprint Review or Retrospect because the Done for the user stories are validated and signed-off by the product owner as accepted. Infact, the Sprint was super flawless, hidden inside the team is the incompetence lying low and the super hero trying to cover it up along the team.

A Scum Master is just not enough to handle situations like this. We needed a Coach here to make the team understand what they were supposed to do.


As a team for each sprint, we deliver, but not over deliver it. In highly self organized teams, the threat shadows itself and grows as a poison tree. The super heroes, thinking of helping junior peers, coding for them and claiming they have done it, is a way of spoiling the guy who looks you as a senior. The candidate should train, guide the juniors to perform the action than to do things on his own.

Scrum Master:

Impediments are to be solved or guided by a Scrum Master who has to be a technical guy in a tactical project. If he is just another Project Manager moved role, then it becomes a clear problem that is buried within a team and never showed up. In Scrum, we need to remember it’s a team’s delivery not a single person who can prove the sprint to be right.

This is a hidden, secret layer that cant be found unless you go a step ahead with the team and understand what each person deliver. In my experience, even if you have been honest with the team, the team never shows up that there was something hidden. For the sake of being good hero, outside but what each individual misses is that their learning curve is pulled by his senior and at the end of the day, he doesn’t really know what went on with project or how it was ever coded.

Why do these heroes do this?

From my experience,

  1. It’s for them to prove that they can deliver technically anything and they want their expert light bulb above them.
  2. The thirst to qualify and get a good rating and prove technically strong caps.
  3. To impress junior or senior peers
  4. As a challenge, to fight with self ego’s
  5. Innocently, they overdo, just to prove.
  6. Rightly to beat their velocity Sprint after Sprint.

There is a parallel threat that runs with this, the velocity is being observed not as a team but by a single resources doubled up velocity and there starts the waterfall model as the resources who are waiting to get their work done spend quality time doing all sorts of other works.

How do we identify the secret as a Scrum Master?

  1. In Daily Standup we don’t hear any impediments
  2. Even if we hear, they are solved or can be solved by today or a specific day
  3. Details on impediments aren’t shared by the team.
  4. Team considers every risk to be an impediment.
  5. Team member doesn’t provide an update or deliberately avoid a specific update.
  6. Team member deliberately absent for a update that he needs to share on a day.
  7. Team member has resistance in volunteering to pick up user stories.
  8. Team member depends on senior resources (super heroes) in the team to suggest, picking up user stories.
  9. Team member informs that he would not be available today for the daily standup.

The above are some of the symptoms that I have faced as a Scrum Master. Watching the sprints deliver perfectly at the end and being dumb.

What can be done:

  1. Discuss it personally with the resource. Understand his problem and start assigning him a mentor to help him learn where he’s week at.
  2. Remove him from the Scrum Team. (Make him an observer for a sprint)
  3. Give him or allow him to take simple tasks from the backlog (planned for other sprints) to work on.
  4. Have a personal stand-up with him on daily basis to understand three things. (What did he learn or do yesterday, what is he going to learn or do today, what is the proof?)
  5. Just by assigning him / her to a mentor or getting them a training tickets to attend training does not make him a hero overnight.
  6. As a human, he takes his turn to understand that he has done a mistake; he first tries to cover it up with guilt. Then he tries to recover from his act, He anticipates and understands the move forward. This is the time you as an assistant provide him the tools for him to grow. Infact his is one of the best things a Scrum Master can do to his team ever.
Leave a comment

Posted by on October 13, 2011 in New forms in Agile


Tags: , , , , ,

Waterfall inside a Sprint

There were 2 serious problems that we encountered and learned from our mistakes. We were biased with waterfall model or the only model that we knew how to manage / run a software project.

Running a waterfall model inside a sprint.


When the sprint starts rolling even on the first day, a user story is taken by a developer and starts to actual code the piece of information. At the same time the tester creates the test scripts based on the test plan detailed in sprint planning.

On the day one, the daily standup are normally missed or happens for less than 10 minutes for the working group to pickup on the activities that they have agreed on the Sprint Planning. For a 30 day Sprint, effectively we would have 29 Daily Stand-up’s. On my observation, I have found 20% of 29 days to be greatly effective and remaining 70% is just tracking and in progress status and 10% of 29 days to be very ineffective.

The 20% is again split up in the start of the sprint where the coder actually starts working on the first piece where he has actually made his mind to stick with the promised schedule and he gets it 90% of the time. The second gear up actually happen just 2 or 3 days before the sprint ends. The fast tracking or eventually working hard to deliver is in every once mind. Over a period of time, when the team gets matured, they understand this really happens in self organized teams.

The 70% is the actual threat where we by mistake fall into a waterfall model, unknowingly due to delays (may be) even from a single resource standpoint. Once a delay is found or the velocity of the team moves to and fro, the shift affects the next step to happen. (That itself falls unknowingly, into waterfall)

The developer delayed the process by 2 days and starts to work on Task B with a delay of 2 days, the tester has no work for 2 days, including the other parties, over a period of time, we could see the developers creates function after function and tester testing features after features inside the sprint, we run a waterfall without even knowing its run one after the other, one being depended on the other, one waiting for work and one extending or delaying what was promised.

It is actually a complicated process to run parallel, with test sprint run to find the team’s velocity and over a period of executed content, it gives you the truth, the fact of what really can be delivered as a team, not as an individual. The PDCA cycle pulls the dirt and show off the real threat.

A highly self organized team provides 100% results. The threat is not if they produce less than 100%, the threat is when the team produces more than 100%. The Scrum Master changes the velocity of the team and it grows with a decent run. Most of the times, in my practices, I have seen teams take the best velocity to run the sprint, on the 70% in progress meet-ups on daily scrum, they take more user stories performing the actual calculation of Sizing, Duration fix and Schedule draw. And on the flow, the user stories that have picked up are left without a single work done due to the test bugs that had to be reworked or completed in full that pulls the velocity of the person or the team to a positive side. On the next Sprint if the Scrum Master decides to go with the best bet for the resource, It becomes even more a cumbersome process to detail the real value. Its fine if the velocity and the deliverable can be managed but each time the sprint runs, it has to be managed well. The Scrum Master gets the experience of validating the real velocity to go in comes with running few sprints and experience.

The problem of estimating features is a continuous process as features are always and mostly different from one another. When we spend time to create a feature and label it “Done” we also take a measure to see if that can be automated. The time taken to automate the feature would be normally 5% of the estimated user story size. This is sometimes a kill when we automate a feature and when we try to use it, the same 5% goes in integration even if the feature is ready to plug and play. The save is only for the testers who do not recreate the scripts to run.

We have our User stories complete, An acceptance criteria and a proper done statement, Next in line are estimating the size, Deriving a duration (using the velocity) and draw a schedule. We do them one after the other and continue till we reach the end of the velocity. Here we are running a clear waterfall model that can’t be stopped. Over a period of time, the team understands with a shock on both the cases to feel that they are not doing an iterative mode. They have unknowingly trapped in the waterfall model and the way to stop is to terminate the sprint and start working on with the Sprint Review and Retrospect to identify where we could change.

Terminating a Sprint is not as easy as it takes, as we would be running in the 70% in progress status. There are deliverables half done and team members waiting for their share to shed. It becomes a cumbersome war in between the team to deliver. The elasticity of the team would help it bring over few portions of digestible delivery. If the Sprint is terminated and has to restart, the work doesn’t restart from scratch but from the part that was half done but the estimate(size) in full. 


If you are starting to follow Scrum, I would highly suggest to run demo sprint of full 2 rounds with the executing team to understand how it work. Even before following Scrum make sure you have a proper need to use Scrum. Threats like this are lessons learned from my practices.


Posted by on October 5, 2011 in New forms in Agile


Tags: , , , , , , ,

Ah, I don’t want 2 work on US time

Collocating or Co-locating them and performing the delivery using Scrum was a nightmare in our organization. We use to have re-organizations twice a year. The need was to be aligned with the function or with the business or within the business function.

Prior to this, our re-orgs were more towards technology like Java Unit, Microsoft Unit, which had sub units Front End , Back – end and then version wise split up Java 1.2 Sub unit Java 2.0 …. It was a mad rat race….

 Delivering becomes even more cumbersome as the front end guys needs to collocate and need a separate infrastructure and when they were integrating their process they need the testers who needs to be borrowed for a period of time and then returned back. No dedicated testing, BA resources were provided for a development team.  They need to collocate for a period of time. Infact this led to creating a pooling structure for BA’s, Testers and they formed a unit, sub unit and a department for them. The billing become more holy and the process became the cow. These departments gave birth to a sibling Technical writers and it race raped a new breed of Document Writers, Critics and User Manual creators, Automaters and on… At the end of the day, we had hybrid teams in a department collocated working on a technology where the technology breeds a dozen on the weekends with new versions zipping our lives.

It was a real mad rate race.

Aligning to business itself is a threat, as the vision for the business is strategic and anything strategic has a dynamic weather change. The rolling up was much easier in this end but when another re-org needs to happen it again became cumbersome.

Aligning  with the function or a service was ideal, where we really found cross generations of ppl work in a team. Every organization that is on the way to become a matured hybrid should have undergone all these kind of alignments, vertical, horizontal, funnel down, up and undressed to show the value of joined up teams.

Yesterday, It was a dull client – customer – development team hybrid where the clients / customers were in the East or West, the development, testing centers were in India and China to work and deliver the content. Forming Scrum teams were a challenge, a huge impact on teams that were in US and India, where the Indian developers needs to work on the US time just to clarify doubts, prototype and present what has been done.

Today, A much energertic approach in handling clients have been found and practiced in organizations like mine. We have replaced the word Clients / customers with ‘In-Country colleagues’. They aren’t clients, but our team members who work in other locations. The idea is to help us help them. Some organizations called this joined up.


Tomorrow, As I blog, Our Team has picked up 2 or 4 members from our In-country colleagues to collocate to India and spend solid 2 years in helping us helping them, to shape up the product, to help us understand the big picture than just the scrum team or the sprint deliverable.


The advantages are…

  1. We don’t worry about Scrum of Scrums
  2. We aren’t delayed to get first hand information.
  3. We have the team collocated. (Clients, Stakeholders, BA’s, Testers, Development team and SME’s) all in one place to deliver what is required like a mission critical delivery.
  4. We save time and focus on results.
  5. We buy in. When your clients sits with you while you develop, while you prototype, while you present make a lot of transparency, confidence in delivering and a much positive attitude to deliver what is required.
  6. It helps both the members to learn from each culture / psychology and human network.

This is how a Scrum team should be… If you have your clients in the US and UK, Suggest to your management to bring the key resources for a period of 3 sprints to your developing arena and see the difference of how your team can perform. I have seen IBM, Microsoft and other companies who follow this.

I have learned this over the period of two years what Scrum meant by collocating.

The graphics in the blog are not self created but gathered from internet google search.
Leave a comment

Posted by on October 4, 2011 in New forms in Agile


Tags: , , , , , , , ,


SM Cap


Software Projects fail, mostly in the waterfall model. Period, The Project Manager is blamed at most times. One of the key effectiveness in the failure is the tool-centric process or Process-centric tools. The time taken to effectively learn a process, its entire life cycle and how it could be used is missed drastically by most project managers, even if they are qualified and certified. Agile practices are to be tried to roll to perfection.

Replacing a Project Manager in the middle of the project with another Project Manager is a kill to the project. These risks are never taken and if taken by chance, a clear knowledge transfer (KT) that runs to months are formed by organizations. The question points to why this is a kill? Is the project manager the driver of the project? No. He is the driver of the process. This is missed from the organization point of view. The project changes or fails due to the unclear understanding or misunderstanding by the stakeholders (en all).

These points to majority of the work that is done below: 

  1. Awarding Client relationship and the movement to a new manager is a threat.
  2. Project documents collected and reviewed need to be agreed and reorganized.
  3. Direct Reports have a psychological issue.
  4. The threat of the new manager taking command and new directions along with the results of the direction are threats.
  5. Time to settle down in the new arena is a dead time.
  6. Above all, the organizations power to substitute a time centric manager for an on-going project is critical and a threat.

What if the project is in an agile model with a Scrum Master (SM) at work? These above threats are never felt in the first place. The power of the designation is as simple as a practicing Scrum Master. (above all).

 Scrum Table

I have the art practiced in moving SM from one project to another in different phases of Scrum. I have seen the effectiveness of how a master can work with his inputs to yield super deliverables, “the threat of moving, replacing the efficient Scrum Master is not a threat but the ability the position gives you to handle your projects”.

The Scrum Master is not a project Manager but a facilitator, Coach, mentor and a practice guide. In transforming organizations and transformations projects, The SM is the 361 degree key. (361 degree is a level above 360 as 360 is also 0 at a point in time).

Why do people transform or change the way they deliver software projects?

I have seen projects that span years with their vision statement changing once in year,

  • Changes to the organization hierarchy happen in a pizza move.
  • Alignment to the Business Idea or Value,
  • Core Strategic makeover,
  • Technology subversion
  • Logistical transformation
  • Cultural dependencies
  • Compliance guarantee. &
  • Requirement for a project all keep changing all the time, just to reflect what the business ultimately wants to do.

Improvise trends, use newer, safer technologies and work with unanticipated change and anticipated risk has become more of a sign language. Leaders in the organization think wide with the current role or fade it away with their juniors who are informed leaders at most times and just plug and play the game called change.

Today Leaders showcase “Change” as a centric, dynamic and objective oriented approach with a strategy build over in multiple loops. Yet they fail to deliver what is expected at the end of the deliverable. As I have seen it, the failure itself brings the need for the change. Then there is another new game to start with.

End of the deliverable is what needs to be changed. The deliverable should be progressive, measured and on the move of inspect and adapt approach. In-fact other than the software development industry (as a whole), most business does a unknown mistake and learns from it, recovers from it and draw a tar road to allow people to follow and miss the holes. But here, in the software development industry, there are proven ways to fall and ultimately points to the managers who hold the failure. The failure is known for sure over the period of changing. The only reason is because the organization focus is on the change and not on the fall back of the change. The sure reason why Scrum is effective today is for the same reason.

Today, the software industry needs the change to prove the platform can be solid to multiply its branches above than re-engineering the platform, again and again. The computing industry is starving with known failures from the waterfall model and each organization has in one way or the other seen, felt and failed multiple times.

Change itself should be digested as a process than looking at it as a new paradigm in shift. The core of change is static, if a change is envisioned to a business model of shifting things or a strategic change to pull over sheets of vertical and horizontal moves, it still doesn’t change the core of applying process to a set of defined way of working. This can be termed as Change Innovation. Where change is continuous and the methods or approach towards them are new. 

The guy who is ready for the change, ready to take the ball and being prepared to play the Rubix from any point is a Scrum Master. He understand where he stands now, what he needs to do, perform a change when required and go back to the place he belongs.

From (Do Better Scrum – Peter Hundermark)

The responsibilities of the SM role are:

  • Empowering and shepherding the team.
  • Removing impediments
  • Keeping the process moving
  • Socialising Scrum to the greater organization.
Recruiting SM

 Recruiting the Scrum Master

Its one of the hard challenges to find a really qualified Project Manager to manage a similar, scaled project. Its quiet easy to find a Scrum Master.

 While recruiting a Scrum Mater, I have found and used the following:

  1. Is the master trained?
  2. Is the master certified or planned for a certification?
  3. Can he present what lessons he learned while practicing scrum?
  4. Can he start a new scrum team and follow process?
  5. Is he detailed oriented?
  6. Does he have the courage to speak what the truth is?
  7. Ways that he performs a Sprint Daily Standup?
  8. Ways he helps / coaches to clear away impediments
  9. Solutions that he can bring in a scenario.
  10. His skills in introspecting and retrospecting.
  11. Can he follow process? ( I don’t want a innovator here)
  12. Finally, what is his personal interest in growing up?


Forming a new Organization Change (Role of the SM)

The framework which is the body of Scrum should be well defined by a SM. He should be able to adapt himself best as a coach, to a mentor and facilitator when needed.

As a coach, I would admire the capabilities of a SM to teach the basic principles. Stick with time-boxed practices, detail results of what was expected and if it was achieved and further to anticipate and work with risks that he may come across in the future.

Even though risk planning is not a part of the game and we require it on daily basis to understand while working with impediments.

As a mentor, I would like him to scale from a manager to boss, to make sure peers follow procedure, understand and create a cross functional team, work with multi talents and have a clear collaboration ticket while dealing with resources.

There are known risks that I have seen over the past that the mentoring changes to bossing and practise rude rules to follow procedures. I would like to handle them with maturity and politely as possible and when required to be real rude, bring in an essence of the act wouldn’t be willing.

While in the process of creating a self organized culture, we make several mistakes, one of the common one is to forget what the individual tries to achieve as best as it can be. “To code, To test, To deliver”. Scrum is just a walnut shield. The core being nuts cannot be avoided. We need to be matured enough to thing deliver is important in the framework of scrum in regular intervals and we need to keep the space in between to make sure the resource understand the need to deliver in the framework. Mostly of what I’ve seen is the framework being important than the deliverable.

As a facilitator, I would like my SM to be thinking before time, being an active participant in the Sprint Planning I & II, Sprint Review and Retrospect and identify, inspect and adapt principles at all times. He should be a core replacement or sometimes fully responsible for the changes in the Sprint backlog, release planning and burn downs and up charts.

Lastly, I would love him on the attitude he has with the framework, not as an innovator but to ideate process in bringing peers to communicate, collaborate and co-ordinate clearly.

A New Scrum Team

A perfect place, to perform. New organizations or communities of projects that are formed are the perfect place to start a scrum or transform to scrum. Even if the requirements are frozen, estimated and risks analyzed, Scrum gives you the opportunity to gel well.

The Appointed SM, should be a team player to understand what he needs to deliver. Be aligned with the process and make sure he is available at all time with the team to remove impediments.

  • His active role would be to train team members on ground rules of scrum.
  • Aid with Stories, Epic’s & Theme creations.
  • Planning mechanism to size and create backlogs.
  • Spread the value of volunteering, the freedom Scrum gives to perfect what a resource could do all by himself to learn and grow.
  • Practice Daily standups and stick to the time.
  • Make sure the team members efficiently create a self sustained organization of solid deliverable’s.
  • Help team members in show casing what has been completed in Sprint Review and be a proactive member, inspecting and adopting in Retrospect.

Hand in Hand with the Product Owner

Scrum Master and Product Owner should know each other well and have a good rapport.  It is extremely essential to think our product owner is our internal customer. He creates and maintains the Product Backlog with the help of the team. The SM should keep the Product Owner informed at all times, including the Sprint Planning 1 (and if needed) Sprint Planning 2. The major stakeholder’s vision should be digested and the deliverable showcased properly in Sprint Review and Retrospect.

In our office, we have a dashboard in a meeting room where the artifacts are placed at all times. (Prior to use of the customized software program). All our meetings happen in the same room and outside the room we all share common desks other than the Product Owner. PO doesn’t share desks and he is seated at the same floor in corners of the building.

As we work in an Agile Platform, our bills are totally different from waterfall model billings. Each day the Scrum Master takes an extra effort to work down the ‘Resource Allocation Planned vs. Executed’ with the help of burn down charts and actual hours indicated by the resource. We have principled that our offices in India close by 5:30 for all development and testing teams and 15 minutes of time is taken out to fill the hour sheet for that date.

This information is collated and global billing sheets are updated each day, till the Sprint review to create the invoice for the Sprint by the practicing SM. Our clients are well aware of day to day chargeback details as they are available on the Sharepoint that our clients can access.


Sprint, Release Planning 1 & 2

One of the most important activity in Scrum that helps the entire team to focus on risks, estimation, tasks breakdown and incremental deliverables.

SM should invite the Product Owner and make sure his participation is valued as he guides the team in the right direction. SM should also bring in required stakeholders needed to guide the team in understanding requirements.

With my experience, I strongly recommend to have this meeting well planned for a whole day to focus on the requirement and baseline it.

Velocity is planned in the phase, updated on the Sprint Review for the next Sprint.


Daily Scrum Meeting:

The primary host of the meeting is the Scrum Master. A single meeting would be able to show us how the scrum framework is followed in the project. The SM, learns, inspects, adapts and guides the entire team on the next move to win the game.

Few activities in the daily scrum apart from the 3 questions:

  1. Make sure each resource has specific task’s to do.
  2. The task’s are estimated, sized and prioritized (not ordered).
  3. The tasks are in the order of execution or helps to delivery the package to the current Sprint.
  4. Make a note of repeated events and by repeated team members on impediments.
  5. Track and resolve the impediments list on priority (urgency).
  6. Track team members idle time and leave details.

Once the meeting is over, The SM should start capturing values in the Risk Register, Impediments list, Cross check the product Burn down chart and finally inform the Product Owner if there are specific events that needs to be discussed. (Discussions doesn’t happen on daily basis after the Daily Stand-Up, Its only when events or incidents have happened).


Sprint Review

The most crucial part of a Scrum is the Review. In our organization, we have dedicated Quality & Planning team (Q&P) who are a part of each Sprint Review. (They are previously involved in Sprint Planning too). We have divided our Sprint Review into 2 parts.

SR Part 1

Here each resource provides statistics on the individual velocity, no of user stories completed and done. This is compared with the Resource allocation, Task allocation, Product Breakdown chart, Testing related details and Quality Metrics used.

We have brought in Functional Point (FP) Estimation along with PP to estimate sizes for our user stories. The stats are again validated on the SR1.

No demo is showcased here.

SR Part 2

Each resource showcases a demo in an ordered method of their inputs and output and what process has been worked. This confirms with the agreed Done statement of the deliverable which is signed by the SM.

No stats are discussed here.

Our SR’s gives us a clear indication of our agreed ‘Done’ statement to deliver the results for the Sprint. It specifically showcases the “dirt”, both in stats and demos and helps the SM to identify and zero the problem if he has missed it in Daily Stand-Ups and creates a way to rework and adapt an appropriate solution for the sprint.

When the Program / Account / Portfolio manager is involved in a Sprit Review, it helps them to understand how the framework is effectively used or ineffectively individual’s activity and showcases what needs to be done focusing on the solution.


Sprint Retrospect

Immediately follows our Sprint Review on the same day or the following day and no activities are done in between these two meetings.

Notes from the SR Part 1 are taken to make any process improvements, quality changes and allows the SM to guide the team.

The meeting is normally closed door. Only the Scrum members including the PO & SM are involved. Here everyone takes a turn to speak what they have done best and what they could have done best. We also take turn to “Start”, “Continue” & “Stop” activities inside the team.

When SM and PO takes turn to introspect, they make sure they spill the dirt outside and make sure the whole Scrum team works for the vision that has been defined. Many times, in my organization this has become a war room, with maturity over a period of time, we understood what needs to be done as a team than to find difference between each other.

The phase plays an important role if there is a Sprint termination during the execution of the sprint.


SM Artifacts

The SM works with the following artifacts in creating, updating on a regular basis.

  1. Resource Allocation.
  2. Resource Utilization.
  3. Resource Leave Calendar
  4. Notes (from Sprint Planning, Daily Stand-up, Sprint Review & Retrospect and Process Improvement)
  5. Sprint, Release, Impediment & Product Backlogs.
  6. Burn down/up Charts
  7. Risk Register
  8. Velocity Chart
  9. Tools:
    1. Planning Poker
    2. Functional Point Estimation Template
    3. Story Cards
    4. Process Improvement Template
    5. Lessons Learnt Template

Texts marked in Italics are not a part of Scrum and followed by our organization.


Day2Day activities

Tomorrow is just going to be like today as it was just like yesterday is not the agenda for a Scrum Master. Each day is a challenge, struggle, lot of quality paper work and lot of planning to be “Done” to deliver what is planned.

The day starts with a Daily Standup, if necessary Scrum of Scrum, Updates to the burn downs, updates to the resource allocation, utilization, update to the backlogs and reports to the PO.


Sprint Termination

Rarely in a case does the Sprint terminate? I have seen close to 6 Scrum sprints being terminated. One of the obvious reasons where I had found 2 cases where the Master was just a project manager to handle things and the team weren’t educated on what needs to be done from their end. The sprint dint last for 3rd cycle and the backlog was still untouched.

In a particular case, the project manager was a SM had no backlog and had all in his mind the Sprint backlog was a set of requirement documents that kept revisions in the version as detailed design documents.

A recent show that I witnessed was in a transformation project, when they wanted to move from a waterfall model to scrum and moved in the coding phase and started up by having a standup for 2 hours each day. The deliverable was really messy as peers dint want to volunteer to work and the named SM had to push the WBS tasks to each.

Whatz Next to Scrum Master

Moving up the ladder is not so easy, Practicing Scrum as a Master is a continuous learning process as each project differs in resources, magnitude and deliverables. The role helps you to look to a project level, growing up or Scrum of Scrum and becoming a professional or a coach should be the target. Most SM practise coaching as a day to day operation and facilitates process to deliver high valued, incremental deliverables. Using this as your key stone, the next move is to certify yourself in CSP and raise the community and the framework as a Coach.

To conclude, I would use (Do Better Scrum – Peter) words that follows as…

 he SM role must provide process leadership to the rest of the Scrum Team and to the rest of the organization. Classroom training, such as the Certified SM course, is an insufficient means to gain the required tacit knowledge to master Agile practices and the Scrum framework. The team and the organization need the skills of an experienced practitioner to guide them through the maze of challenges they will inevitably face in transitioning to Agile.

Leave a comment

Posted by on September 22, 2011 in New forms in Agile


Tags: , , , , , , , , , , , , , , , , , , , , ,

Maria Montessori + Agile Thinking = Scrum

As a pupil, I have attended a regular school. The oldest Salesians of DB School in Chennai. The teachings were Anglo India. As I grew up to an adult, I learned the Montessori way of learning was with freedom and enjoyment.

My daughter, 6 years old is studying in a Montessori with the freedom she requires, as a parent coordinator, it has been an easy plot to understand what my child learns, how she learns it, alphabets, numbers, shapes, calculations, ordering, life size real examples…

I started to attend few classes as a silent listener and a volunteer to help when necessary.

The overview I picked from wikipedia on Montessori education gives us an idea to compare, here you go…

Montessori education is characterized by an emphasis on independence, freedom within limits, and respect for a child’s natural psychological development, as well as technological advancements in society.

Montessori education


Mixed age classrooms, with classrooms for children aged 2½ or 3 to 6 years old by far the most common Cross-Functional Teams
Student choice of activity from within a prescribed range of options Tasks Pickup by voluntary method
Uninterrupted blocks of work time Sprints
A Constructivism or “discovery” model, where students learn concepts from working with materials, rather than by direct instruction Story boards to epic, theme creations and poker planning.
Specialized educational materials developed by Montessori and her collaborators Poker Planning, estimation techniques, Sprint and Release Planning


When the school starts, it doesn’t start with an assembly with prayers, but each class of 20 students meet-up in  a circle, without a word maintaining silence and they say what they learnt yesterday, what they like to learn today. Just like our Sprint meeting where we answer the 3 questions with well prepared answers with a time boxed meeting.

Each child chooses what they want to do. Walk away from the circle, collects the tools they want to learn walks back to the circle and the teacher or a matured / senior child helps the younger child to learn the concepts. End of the day or over a week the child learns the concepts with several practical questions answered all by him.

Themes, Epics & Storyboards

To understand, let me take an example… Swetha, walked out of the ring, collected a world atlas puzzle made of wood. She is 5 years old and doesn’t understand what it is. As a game to arrange things was the only thought she should have had while picking up the material. Her senior Tony guided her and explained her about the countries, Jason explained about the land where we are and the countries with seas in between, The discussion went to different types of travel, things the world is made of, shape of the world, size of the world, the universe, the things around it, how is date and time calculated? How is the day changing to night? Not just in a single class but within a week Swetha was able to understand at her age of 5, the things that we understood in a regular science book from 5th to 8th grade. As Tony & Jason both 6 years old share their knowledge, they gain knowledge in answering them and strengthening their base of what they like.

Performance Reviews

When Swetha, did her learning with the atlas puzzle, she was questioned by her teacher, her guide. Swetha, can you draw an atlas by yourself? Can you show me where India is? What is the country above India? Can you tell me a story of the atlas? And more….


As a parent, to learn your child has scored in a regular school is in a way of tests / exams. In Montessori, the performance is evaluated over a period of time, not in a fixed test / exams format with questions to be answered and answered correctly including the ranking that kills the budding minds.

Swetha draws and describes in her level of English what she understood about the atlas puzzle and amazingly covers most of what was discussed. Her single story had a king longing on day 1 to wait till day 1 of the next month for 12 months to see her queen, where one stay in earth and the other in moon and about the seas and the plants that grown under them, The day changing to night and why shinning stars cannot be seen in day. Finally, the couple ended up after 12 month touring 18 countries that she spelt and wrote.

I haven’t known a better system to teach napkin minds at this age.

Even in a Scrum or a waterfall jaggy model, our performance reviews are made up KPI (Key Point Indicators) or objectives set and broken down to reach targets (Low Targets, High Targets, Stretch Targets) and we basically formulate a calculation for a team of 20 or 40 to rank and provide scores as LMH (Low, Medium or High) or other ways. But the observation on performance is discussed low or never discussed. What has been achieved badly is highlighted more than what is achieved and covered up as a need mostly.


I would recommend leaders and managers to observe, listen and then review each performance with a clear career path in mind for each individual. An associate score card is not a fixed static point, but a way to help him understand that his focus is lost in certain areas, he needs to focus on those areas and his focus is best and when continued would yield these results. These should be documented and tracked.

We need to understand we are working with humans, a fully loveable material who works for us and respects us just because we have the authority. I remember and have seen this quote play well “Give the person the authority and you would see how criminal he is”.

Love Points

The overlap seems to be perfect, the key points that I really liked are

  1. Their daily ring (Standup)
  2. No one assigns tasks, they are voluntarily taken by the child to play way learn.
  3. Mixed age classroom (Cross Functional teams) &
  4. Performance Review.

 We have to heterodox regular methods.

Images are fetched from: “”


Posted by on September 14, 2011 in New forms in Agile


Tags: , , , , ,

Lancinate Old Old product development games

A Cowabunga!, surprised working group with this super idea to reengineer the process. The output being a framework had to support a theory as rock and practise practical small worlds (over & over, again).

On the roll over, it’s a bada-bing, to focus on what really or practically works in software project development and delivery. The rally wasn’t enough we needed Scrum.

It’s quiet inspiring to read the real document “The New New Product Development Game” by “Hirotaka Takeuchi & Ikujiro Nonaka”. If you re-read, it’s a product development game, not just a project development game. The bigger picture was concentrated to use it in different shapes and sizes. Yet today the success was only widely seen in software development projects and growing to other segments.

The differences between the traditional, linear approach to New New product development related with rugby approach is well defined and stated. The game linguistics are used sprinkled over the document and to stress the new casual way of playing seriously.

The document is still an eye opener with out fashioned terms (not in practice now) but gives a new meaning for today’s executives. The 6 characters they used in the puzzle were:

  1. Built-in instability
  2. Self-organizing project teams
  3. Overlapping development phases
  4. Multilearning
  5. Subtle Control
  6. Organizational transfer of learning, are well explained.

Theories and terms as:

Self-organizing Project Teams
            Self-Transcendence (Never ending quest for ‘the limit’),
            Cross-fertilization (members with varying functional specializations)
            (to) Multilevel Learning
            (to) Multifunctional Learning
Subtle Control
            Control by love
            (or even) the common set of values
Transfer of Learning
            Dismantle (the project team) are well stated to a record log along with a set of basic limitations like a product.

Some Limitations that are highlighted are: Cannot use for…

  1. Breakthrough projects that require a revolutionary innovation.
  2. Not Applicable to Mammoth projects like those in aerospace business. & more…

Read the document and sure you would know more just like attending the Scrum Master Class or Product owner class.

Classes are taken by Sathya that particularly highlight the grand fathers and our principles to spread the light of software development business success.

Link to the document: New New Prod Dev Game

Leave a comment

Posted by on September 12, 2011 in New forms in Agile


Tags: , , , , , , , , ,

Agile & Ag_lebra (Algebra)


From my childhood, Mathematics has always inspired me, not as a subject score, but the way basic things  are build & broken, equations expanded & collapsed. It was an exercise to mind to freeze and melt. It was interesting to learn space, graphs and plots and solve equations one at a time to get a definite result and in the case of Algebra, we are sure the result is finite and known at the beginning.

Its is amazing to see the clear overlap using Agile Problem Management techniques, scrum methods to solve a problem, to initiate a process, ultimately to yield a known result. Intersect is so fascinating that we learned and practiced them as we were raised. In current Industry practices what we want to yield is ultimately known or desired or even understood to be known, to Reach to the perfection is where we lack.

Scrum, gives us an opportunity, a clear simple vision to understand how to resolve where we lack, the pathway towards a know destination.  Allow me to give you a solved linear equation:

Solve for x in the following equation:

Complete multiplication:

Group like terms on each side of the equal sign:

Subtract 18 x from both sides of the equation:

Subtract 57 from both sides of the equation:

Divide both sides of the equation by 12 and simplify:

The answer is 

Check the solution by substituting  in the original equation for x. If the left side of the equation equals the right side of the equation after the substitution, you have found the correct answer.

  • Left Side:

  • Right Sides:

Since the left side of the original equation equals the right side of the original equation when the value is substituted for x, the solution  is verified.

You can also check the answer with your calculator: 

  • Left Side:

  • Right Sides:

You can also check the answer by graphing:

(left side of original equation minus right side of original equation). The x-intercept is -5.25.


  • Here Storyboards and epics are defined with a concrete solution.
  • While working in Scrum teams, we choose what to be done and with perform them with integrity.
  • The problem is the current line at work, The solved result is just the line below that makes us break each task to a manageable more concrete finding to another one.
  • Retrospect’s or traceability is narrowed, sharpened and clear to track back the incremental solutions done.
  • Changes are basically a pencil erased solution.
  • Each Standup expands the vision to see where we are, what follows.
  • Each Sprint provides a definite result and a finite incremental release.
  • The graphic representation of the solution is always a breakdown. Just like each statement adds immense value in an linear equation, the points in a product breakdown or release breakdown provides us a vision and slaps us of what we have done and reminds the target fluctuations.
  • The parts of the incremental release is a fantastic finite solution that clears the vision to the next step and once an defect is found, retraces back, just to the next line.
  • What else can be a perfect solution than a solved equation with the precise data that is true, just like our scrum delivered, released and deployed solution.
  • The principles of performing an equation is well understood before even starting a scrum team.

If you are interested to know more, you should attend a fundamental training in project management using Scrum by Sathya and Im sure the learning would be knowledgeable and immense as I do.

Note: The example above is taken from: and not my own creation.


Posted by on September 7, 2011 in New forms in Agile


Tags: , , , , ,