Don’t forget the Tech!

I’m sure Alanis Morrisette would agree with me here, because isn’t it ironic that businesses so often favour pushing out new feature development with complete disregard for the importance and need to keep on top of Tech items, such as tech debt, non-critical defects, upgrades and even license purchases or renewals.

In evangelistic Scrum, we know we have ‘One Backlog’, which contains everything on the Product Owner’s wish list of work items that make up his or her product, including tech items.  We also know that anyone can add to this backlog, such as developers being able to add tech items but only the Product Owner can prioritise this list.

When it comes to managing tech items, I have a slightly different approach for this, and yes, I have broken the One Backlog rule… and yes, it felt good…

I have found that it is a good idea to have a separate Tech Backlog.  The Tech Backlog is exactly what it says on the tin.  It is a prioritised list of Tech items that need refining in order to be added to a sprint. Who owns this backlog, you say?  The Scrum Development Team do.  They all act as one Product Owner to take ownership of the Backlog and make sure the Backlog contains all the items they know of in order to keep the system or product in as good a condition as they can be.  Like any backlog, there may be Epic size items and granular items. Higher priority items should be refined.  In terms of ‘user stories’, I do not ask the team to create user stories for Tech items.  Instead, I ask them to ensure that the item contains enough detail in order for anyone on the team to be able to understand and pick up the item in a sprint.  The term ‘enough detail’ is up to the team.  They should know what that is.  If they don’t add enough detail, then the they are letting themselves down, and they are not ‘setting each other up for success’. Team members should be encouraged to reprimand each other with severe punishments if they do not set each other up for success.  Only joking…. No, the team should be encouraged to communicate effectively so that everyone is aware of what ‘enough detail’ means, if anyone is unclear. Not requiring the creation of a user story is another reason why I think the Tech Backlog should be separate to a new feature backlog.  The people that need to understand the items are technical, therefore I see no need for ubiquitous language via a story. The final benefit is that having a separate backlog that the team manage is easier than them sifting through a larger backlog full of business items they don’t understand or care about yet.  Equally, it would be very hard for Product Owner to be able to prioritise  technical items. An additional benefit to having a separate Tech Backlog is that there is visibility of a Tech Debt problem to a Product driven Business. Having tech debt as long as your arm that is plain for all to see is difficult for even the most archaic Project Manager to argue with.

A way I like to help a team to get organised and take ownership of the Tech Backlog, is by setting up a Tech Backlog Story Time meeting.  For more information on Story Time, check out my blog called Story Time, Yey!

Like the new feature Story Time that involves the Product Owner, the Team hold their own Story Time in order to discuss their candidates for the next sprint from a tech perspective.  Hopefully, the Product Owner should respect the value in tech items and allow either a percentage of the team’s velocity for it or, better still, be open to having as many tech items as the team feel necessary in order to maintain a great system, and support a great product.  A sprint backlog should be the result of a negotiation between Tech needs and Business needs. If your organisation does not respect the need for Tech items, then it’s up to the ScrumMaster to work on some organisational change and start explaining the benefits to key stakeholders.

I usually set up a Tech Backlog Story Time for the team before the New Feature Story Time meeting.  This can be the day before or even an hour before, as long as it’s before. I do this because if their meeting is held before the candidates for new features are known, the team are less likely to be influenced by what the PO wants in the next sprint, and concentrate on what is needed purely from a tech perspective.


So there it is, the Tech Backlog.  A way of keeping track of tech items and chipping away at them in a controlled manner via being organised, discussing priority and negotiating with the Product Owner to get them into a sprint.

Advertisements

But Whyyyyyyyyyyyyyy-y-y-y??

The key to success in Scrum is understanding the WHY’s that underpin the process. Often when teams start out with Scrum, loads of things make absolutely no sense to them.  This is perfectly understandable!

However, over the years I’ve found in many organisations, the WHY’s that are asked of me are often the same.  So, I’ve tried to provide a brief explanation of what my answers are to these frequently asked WHY questions:

  • WHY do we have a stand up when we talk all the time anyway?
  • WHY do we have sprint planning that can take so long?
  • WHY do we estimate in points?
  • WHY are we encouraged to pair program?
  • WHY do we have to go to so many meetings?
  • WHY should we have a physical board as well as a digital system?
  • WHY should we break stories down into tasks?
  • WHY do we have to be disciplined when we are doing fine?
  • WHY do we have user stories?
  • WHY do we have a retrospective every sprint when nothing much changes anyway?

Answers

WHY do we have a stand up when we talk all the time anyway?

Throughout a sprint, the Scrum framework provides ceremonies that are effectively times when the team can ‘inspect and adapt’.  We inspect our progress and adapt if we need to change our direction.  The stand up is one of those ceremonies, and allows us to all get together at least once a day to discuss progress. Often, even though there is a belief that communications are good, teams don’t talk to each other as much as they should.  A lot of useful information comes out at the stand up, and it’s this information that we share that sets us up for the day.  By the end of the stand up, each team member will know what everyone else is up to until the next stand up, so they can orient their own activities in sync with the activities of the team.

WHY do we have sprint planning that can take so long?

The sprint planning meeting is the starting blocks for the sprint.  It takes a long time because we are working with complex software and a lot needs to be considered.  By dismissing the importance of sprint planning a team are inferring that they are not working on a complex system in a complex way.

Without a good start, the team cannot be expected to have a smooth sprint.  If sprint planning is poorly executed and corners are cut, often the team find they have to make up for it later within the sprint which contributes to slowing them down and potentially missing the sprint goal.  Activities like clarifying requirements, realising too late in the sprint that need more information from an outside source, or realising they have overcommitted due to a lack of understanding of complexity can be avoided by engaging in sprint planning properly.

Spending time at the beginning of the sprint saves time during the sprint.  Two heads are better than one, so six or more heads are definitely better than one! Going through sprint planning together gets everyone off to the same start right from the beginning and allows everyone on the team to input their thoughts and concerns when breaking down stories into tasks.

WHY do we estimate in points?

We estimate in points because studies show that people estimate more accurately when asked to consider complexity as opposed to time. Time is unpredictable.  A lot of things can happen in a very short space of it.  In addition, in order to estimate complexity consistently it is easier to use a scale to compare complexity of work in a relative fashion.

Scrum uses a Fibonacci based scale for complexity estimation: 1, 2, 3, 5, 8, 13, 20, 40

E.g. put very simplistically,  Story A is 5 points.  Story B is 13 points.  Story C is in need of estimation.  It is more complex than Story A, but less complex than Story B.  Story C is therefore 8 points.

Eventually, as teams become better at Scrum, they perform as a team.  This in turn leads to stable velocity, which is a very powerful tool for the business that helps it predict how to estimate how many sprint a team will need to complete a project.

WHY are we encouraged to pair program?

Pair programming is statistically proven to improve quality.  It does not slow teams down, in fact there is often an increased velocity as a result of pair programming.  When done right, team members talk to each other and work together.  They don’t just sit and watch while another does all the thinking and typing.  They actively contribute as they discuss as they go. Not checking bugs in means developers do not have to context switch to return to the bug later in the sprint.  In addition ‘pair programming’ isn’t limited to dev/dev pairing.  It also includes dev/test pairing.  This combination is very successful as it brings test into the picture before work is checked in, meaning that less defects are created and found further up the sprint.

Pairing is not mandatory as part of the Scrum Process, but it is considered best practice if the circumstances permit it.

WHY do we have to go to so many meetings?

As part of a Scrum team, your role as technical experts is respected to the point that the business do not want teams to just develop the product in the Construction phase, they want you to take active involvement in the evolution of a product from the beginning.  As part of a collaborative organisation, your inputs will shape the product as we go to ensure we deliver the best outcomes for the customer.  Therefore, we need to have the meetings we have to make sure that we are all talking to the right people at the right time.  In Scrum, we do this via the ceremonies which are all designed for very specific purposes in order to get the right outcomes when they are needed at different points within the sprint, such as:

  • Pool and develop ideas
  • Plan our approach
  • Make decisions
  • Create and develop understanding
  • Encourage enthusiasm and initiative
  • Provide a sense of direction and a common purpose

If we do not have these meetings, we often lose the collaborative element that makes Scrum so successful.

WHY should we have a physical board as well as a digital system?

Often teams do not fully appreciate the benefits of a physical board until they have tried it for a few sprints and have experienced the difference it makes for themselves.  The physical board is fundamental in assisting a team to collaborative working, which is a benefit that outweighs the perceived cost of duplication.   A physical board provides a physical presence for the team.  They can meet at the board to discuss work, have the stand up around it and physically move stickies that represent work from one state to another.  If you work in a distributed team, you can set up a rota for an offsite coordinator, where someone is the point of contact for off-site team members to contact in order to update their work on the board for them.  The main benefit of a board is visibility.  It is very easy to see on a physical board who is doing what at all times.  The board can be configured to suit way that best befits to work streams of the team without the need for write permissions what you might get on a digital system.  The board is a tool to help the team work better together.

WHY should we break stories down into tasks?

The reason we do this is so that we think more carefully about what is involved in the story.  Often it is not realised how complex a story is until they are broken down into tasks at sprint planning.  Breaking down a story into tasks allows more than one developer to work on a story at once so that the story can get into test earlier.  Obviously this could happen without tasks, but it is more visible who is doing what when tasks are in use.

WHY do we have to be disciplined when we are doing fine?

The question to ask here is, “fine compared to what?”.  If a team has nothing to compare their current practices to, then how do they really know how good they are, or even how good they could be?  Unfortunately the perception that Agile is a liberal, anything goes collection of frameworks that some teams have been led to believe they are is inaccurate. If anything, they are the opposite. The emphasis on individual responsibility to collaborate and communicate effectively within the teams mean that discipline is even more necessary so that teams understand WHY it is important to adopt ways of working that consider the team over ourselves. Agile adoption is a journey that involves us continually inspecting, adapting, learning and improving. You should want more for our teams than to be  just ‘fine’.

WHY do we have user stories?

We write user stories for several reasons.

  • They allow the team to understand the context around the requirement.  All user stories should be written “as a… <role> I want… <feature/function> so that…<I get this benefit>
  • The User Story defines the scope of the work, along with the Acceptance Criteria
  • Out of scope stories are more easy to identify than feature lists/functional specs because of their context composure
  • They can be epic or granular, but all can be estimated.

WHY do we have a retrospective every sprint when nothing much changes anyway?

If a team thinks that nothing much changes in a sprint, there is something very wrong.  It is indicative that the team is not challenging themselves to constantly improve or place themselves outside of their comfort zones. Scrum teams are forever evolving, learning teams.  They want to find new and leaner ways of working and embrace the challenge of change.

Don’t just be work mates, be work MATES

The other day I was sat on the tram as usual deep in thought about what makes great Scrum teams.  I cast my mind back to previous places I have worked, where I work now and what I liked about various places and the people within them.  It may seem pretty obvious, but when I thought about it, it wasn’t actually the way places adopted Scrum like a boss, or how they smashed through the sprints with high quality software and excellent communication and collaboration.  Obviously I liked these things millions and it made me very proud of the teams, but what actually made certain places better than others was the friendships between myself and my colleagues.

One place I was at for a while had a different lunch venue for nearly every day of the week and it was the norm for most people to go to these places without fail.  I recall Mumtaz Monday, Orange Wednesday, Adelphi Friday…  Going out for drinks after work was also pretty frequent, and the great thing was that when this happened, it was always great fun. It wasn’t just about eating and drinking though, people did fitness stuff together, hill-walking, running or cycling for example (I used to join in the running at lunchtimes. Running with boys is hard. How came they can all run so damn fast?!).

Another place I was at went to the pub most Wednesdays and/or Fridays to what can only be described as the rankest food in the area in the scuzziest pub (it was called ‘The Dragon’, but was affectionately yet appropriately nicknamed ‘The Drag’), yet a good turnout of people still regularly went?  Sometimes if The Drag was out, they would also even drive in convoy across town to have lunch with their buddies in a different office twenty minutes away!

There are a more places like this that I can cast my mind back to; where the culture is sociable and inclusive; places from where I still keep in touch with my work mates.

But what about other places not like this?  What were they like and how did it impact the culture?  Well, I can think of one or two places where work mates were not ‘mates’.  Where people turn up for work and just tolerate each other and go home.  They don’t really want to be friends.  They just want to work and keep their own time their own.  Although I can get that, personally I think, well, it’s not cool. I didn’t like it. Places like this can be pretty lonely, actually. You can’t have much fun when people don’t want to be fun. You can’t make friends when people don’t want to be friends.

So why are some places better at being mates than others?  For me, I think it’s all about getting a good cultural fit at the recruitment phase.  There’s that argument of ‘we need a mix of personalities’, but I’m not so sure I buy that.  I think having extremes in groups makes it too diverse.  Having like-minded people who will get on is much more likely to be a sociable group that genuinely like each other, and in turn, a more successful Scrum team.

I’ve noticed that teams in a good cultured company hang out together.  They know each other’s hobbies.  They know where each other live and what their partner’s names are. They go for lunch together and for drinks after work and do fun stuff together.

I don’t think it’s hard to get teams to this place with a bit of encouragement from management.  If you notice your team aren’t hanging out much, facilitate something for them to do so!  Organise a lunch together, or some drinks after work.  Go paint-balling or something, anything fun!  The key is to do this regularly.  Don’t just organise something once and that’s it.  Organise 6 months’ worth of stuff.  If your fist attempt was a bit of a flop, try something else.  I usually find anything to do with alcohol tends to be successful. Organising socials will help people just get to know each other.  Its amazing what your colleagues get up to in their spare time and you had no idea.  Help people come out of their shells a bit and start being more up for hanging out.

In conclusion, don’t be just work mates, be work MATES.

Agile…what are you liiikkee??

You need to say the title of this blog like someone in Eastenders: “What are you liiiiike, ey, Agile? What are you liiike?”.

Alright, alriiiiight, have a seat on your bottle and glass and and feast your mince pies on this little analogy I have for you.
Over the Easter weekend I went down to Anglesey with my boyfriend and his entire family (it was my first time I’d spent a long time with them all…I was terrified…so many things could have gone wrong…what if I broke their favourite plant pot or got sugar in the wrong coffee?  What if I blurt out some nervous, inappropriate drivel and make them hate me for ever?? It was a big deal!  However, I was very proud of myself for not making a complete butt of myself, so, yey, go me…Anyway, I digress…).
So part of this little holiday involved me thinking it would be nice to make breakfast for everyone on Easter Saturday…I offered to make scrambled eggs on toast.  I’m good at scrambled eggs and people like my scrambled eggs.  I think perhaps because I load them up with butter it goes all like, nom nom nom. It was a safe bet.  Not risky like poached eggs or even fried. Scrambled was goooood. I’m good at toast too.  Toast is also goooood. So, off I went and set to work.  I’d broken the eggs and got working them in the pan and after about 10 minutes of me working, his mum and niece (7 years old), come in and ask me “will you need toast?” “Yes” I say, as I’m thinking “OH NO I FORGOT ABOUT THE BLOODY TOAST! HOW CAN YOU HAVE SCRAMBLED EGGS ON TOAST WITHOUT TOAST??!” Thoughts of how to juggle copious toasting and buttering with stirring scrambled eggs, or worse, getting the synchronisation of cooking eggs and toasting/buttering aligned to avoid cold breakfast elements caused anxiety levels to rise and dominated my thoughts for a few moments as I processed how the complexity of this ordinarily simple task had just sky rocketed!  I’m just not used to making scrambled eggs at this scale.  I’m obviously inexperienced!
Then, something interesting happened.  I turned around and there was hopefully-one-day-mother-in-law toasting, with hopefully-one-day-neice-in-law-or-whatever-the-name-is buttering.  Huzzahhhhh! Result!  We’d self-organised like a proper little Lean team and and made a nifty little conveyor belt of toasting and buttering, then soon after, adding scrummy scrambled egg.  Breakfast is served! High fives all round.  The other interesting thing is that we had all stuck to doing one thing at a time and didn’t get distracted from our tasks.  We had a grown-up working on the hot hob and another on the hot toaster and a child buttering the toast; we used the skills we had in the group to work together to complete the tasks involved to get the job done, just as a Scrum team should.  And when it was done, we had a delicious breakfast!  Apart from the fact I didn’t cook enough and had to start again…Oh well.  Next time I will know that serving 8 people scrambled eggs definitely requires a minimum of 16 medium sized eggs…
 
 

Amazing Acceptance Criteria: Why AC is OK

I like User Stories to have Acceptance Criteria (AC).  I have many reasons for this. It just makes sense! I do not feel AC encroach on the team’s creativity to satisfy the requirements in the best way they see fit because not all teams are of a level of ability to do this.  In time, and when their Agile experience is more mature then perhaps, and this is to be absolutely encouraged.  Alas, in my experience, it is most often not the case, and teams need more clear guidance until their confident levels increase to the point they can make certain decisions alone.

In addition, If the PO attends Sprint Planning, as they should, negotiation of AC fro a story can take place here if the team have any issues, but at least there is a point for discussion to begin with if AC is present.  It helps clear a load of stuff up and ultimately, ensure the whole team get what they need to do.  Excellent.  Read on for more reasons why I think AC is amazing:

  1. It allows black and white testing.  When the story is in test, the acceptance criteria is met or not.  Test can then easily raise defects on AC’s that they deem not met. they can go over to a developer and say “, Hey, I don’t think you quite met AC.2 here” and they can then argue discuss.
  2. It can help set the development team to used Test Driven Development (TDD) because test do some tests based purely on the AC. they can then populate an automated test suite for regression testing.  Quality!
  3. In the Sprint Review (or before if they get chance), the PO can refuse to accept a user story as ‘Done’ based on a specific AC number that was not met, or can accept it based on the promise that the not met AC is addressed in a new story in another sprint (the AC not met will need to go into the backlog as a story or as part of another story)
  4. AC ensure the scope of a story is not expanded or ‘gold- plated’, which will consume sprint time unnecessarily (see my blog about Sprint Tetris). Developers like to gold plate things, and rightly so! It’s great they want things to be awesome! But sometimes they need a bit of help focusing the awesomeness.
  5. AC allow the PO to explain the requirements very clearly at sprint planning.  When the whole team are on the same page, there is less likelihood that the team will produce something different to what is needed.
  6. When writing stories, adding AC helps the PO judge when a story is getting too big and needs splitting.  As a general rule of thumb, I recommend no more than up to about 5 or 6 AC per story.
  7. Having AC prevents a load of other AC-type rubbish being entered into digital trackers under each story.  One User Story has one set of AC.  Not AC and Definition of Ready and Definition of Done and anything else someone thought of one day).  By the way, the Definition of Done is a separate document that applies to all stories as a whole, not on a story by story basis).

So there you go, why I think AC is awesome.  I hope you do too!

Backlogs and Bugs…

Who ‘owns’ the bugs? Should bugs be included in the backlog? Who decides when bugs should be fixed? How do we decide when a bug should be fixed in sprint?

These are questions I have answered many times, so I thought I’d blog about it!

I believe the PO should own the entire backlog.  A product backlog contains Product Backlog Items (PBI’s).  An ‘Item’ being deliberately nondescript as a Product Backlog does not just contain user stories, it contains all the defects and tasks that the PO knows need to be included in a sprint at some point for the development team to work on. Agile champions One Backlog.  One ‘forced-rank’ list of prioritised PBI’s.  The latter meaning, no two items can carry the same prioritisation.  Something must preside over another, and there is always something, no matter how minor, to determine this. Bugs need to be included in the PB so they can be prioritised.  It may be that in one particular sprint, a few outstanding defects are actually of a higher priority than developing new functionality.

The PO should know their backlog and their product like the back of their hand.  If visibility of the defects are taken out of their backlog and recorded elsewhere instead, the risk is that the PO may lose sight of work that needs doing  and also the impact of a bug on the product may be pacified or forgotten.  Although the dev team are undoubtedly knowledgeable, they are unlikely to know as much as the PO what the impact of not amending, for example,  a cosmetic/UI bug is, because it is the PO who liaises frequently with the customer and understands their pain points.  Something irrelevant to developers may actually be a big deal to the customer.  It is my belief that the PO alone decides what goes into a sprint (based on their backlog prioritisation) unless the team express a technical dependency which will force the stack rank to be changed (stack rank is terminology from Kanban referring to prioritisation).

The tolerance levels to bugs in a sprint is a decision for the teams to make with the product owner, and there are discussion points to consider for every product as a unique entity, and there are reasons for this.  There are obviously standards which are never compromised on, such as no bug that is deemed ‘critical’ should be allowed to be released, but how bugs are categorised is a team decision based on what they believe is acceptable, and the PO needs to have a say in this (but must also be mindful to be realistic).

Tolerance levels outside of critical bugs need to me decided and agreed accordingly and will become part of the dev team’s Definition of Done’. So they need to confirm and document “What is the criteria for a critical bug?”,  “What is the criteria for a non-critical bug that should be fixed in sprint?” . I have not mentioned how to classify a bug not to be fixed in sprint because they should automatically be added to the Backlog by the PO.

The reason I say that all projects need bug tolerances to be decided on a project by project basis is because different customers have different levels of tolerance themselves. For some customers’ products, the PO may not deem cosmetic/UI bugs to be as critical as code bugs and so the tolerance level is lowered on cosmetic/UI bugs.  Alternatively, what if the product you are building is aimed at an audience with impaired sight or learning difficulties?  Perhaps  with the development of these features, cosmetic/UI bugs are deemed of equal importance in all cases and so demand to be completed in the sprint in order for the story to be ‘done’. There may also be bugs that although have been agreed as not necessary to complete in sprint and therefore not a requirement in order for the team to meet the ‘Definition of Done’,  the PO may know it is an exception and so asks the team to fix it in sprint.  The PO must appreciate that this may mean removing another PBI (note I say PBI and not story, as a PBI is an ITEM that can be a task or a bug also)  from the sprint in order for the team to accommodate.

What is a Daily Sprint and when should it be applied?

I have implemented the daily sprint before in teams that are struggling with the fundamentals of working in sprints, mainly, self –organisation and collaboration.

The daily sprint is a concept I have adapted from XP concepts of being able to release shippable code rapidly.

Even though there is a sprint (in our case, a two week sprint), with an overall sprint goal, the team aim to commit to delivering some value on a daily basis.  I can imagine some may be suspicious of this approach already, believing it to be a form of micro-management of the team by the Business.  There is certainly a risk of this if not implemented correctly, and I shall address this later in the blog.  In the meantime, I’ll explain what made me adopt this short-term approach to a team.

The background is that the team had undergone a lot of change through new starters and working on a new project.  A few members of an established, high performing team of four developers and a tester was left with just the tester and one original developer.  The new developers were a mix of junior and more experienced developers taking the developer count to five in total. Obviously if we could have avoided messing with the teams we would, but people leave, things change.  We have to adapt.

So, the changes in a nutshell were:

  • Established team disbanded due to leavers and one of the team being promoted to management and working on other things
  • New team members unfamiliar with systems and the culture of the company
  • A new mix of abilities throughout the team
  • Some strong personalities in within the new starters
  • New starters new to Agile and Scrum process (full training and mentoring was provided)

The Business is generally tolerant of the impact change has on performance, but the above culmination basically led to a poor performing team that didn’t look to be resolving issues itself, even with the help of Retrospectives and mentoring.

After a few sprints with goals missed, the retrospectives revealed to me that the issues lay consistently within the clashes in personalities, individual developments taking ownership of stories instead of allowing transparency within tasks and inadequate communication in general.  For me, a couple of sprints were enough in order to confidently take action towards resolving the issues.  Hence, the daily sprint was introduced.

Now, this option was always intended to be short term.  In my opinion a daily sprint is a means of exposing issues with a team by magnifying problems such as dynamics or lack of knowledge (whether this is process or technical).  The same rules apply to a daily sprint as a longer sprint.  The Definition of Done must be adhered to, blockers and threats to the daily sprint goal must be raised with the ScrumMaster and or Product Owner.  The idea is that if you run a daily sprint goal with teams they will be forced into an intensive mini-sprint, where at the end of the day, the goal is achieved.

The Goals

The development team alone decide the goals at the daily stand up.  For my team, the goals were oriented around which SBI’s would end up where by the end of the day, but can include anything.  The key is that whatever the team commit to is fulfilled on a daily basis.

E.g.

Into Dev Rev

#12345

#67890

Into Test

#09876

#11111

Into Done

#56789

#23456

#78900

As a team, they need to all agree on this commitment, and make it happen.  If the sprint goal is threatened, they need to inform the ScrumMasrter and/or PO.  They need to remove blockers quickly, they need to collaborate, they need to keep each other informed of progress…. But, you MUST let the TEAM decide what they can deliver.  If you don’t allow the team to decide, then you’re in trouble.  The team still needs to be empowered to make decisions in this situation.  It’s not a way for management to impose and dictate deliverables onto the team as punishment for not meeting sprint goals in the past.. They still need to take ownership of their commitments as a team, and they need to remain motivated to do this.

What I found is that, although the team at first were skeptical, they very quickly adapted and started to work better together.  The problematic dynamics were eased as they were practically forced to get along, they were asking me for help more in terms of the process and removing impediments, but most importantly, their productivity increased and they started delivering.  This was a real win because this in turn motivated them, encouraging them to continue with their efforts. As ScrumMaster I observed the team closely and praised them when I saw improvements and was energetic and excited about increased productivity. Its amazing how much of a difference it makes when someone is genuinely rooting for a team to succeed as opposed to rolling their eyes at the stand ups if they are failing.

This approach continued until the product was released several weeks later.  The team then went back to regular sprints with no daily sprint goal with a better appreciation of collaboration, self-organisation and communication, but also, commitment.

Why Sprints Are Like Tetris

Why Sprints are like Tetris

tetris

We are all familiar with the classic game of Tetris, but why is it like a sprint?  Well, as we know the way to score highly in Tetris is to manoeuvre falling shapes to slot next to each other with no spaces so that solid lines are formed.  The solid lines then are removed from the playing area, allowing space for more shapes to fall and be manoeuvred.  If we start allowing space between the shapes into the playing area by not manoeuvring the shapes fast enough, the shapes take up more room and pretty soon, its Game Over.

In Sprint, it is the Scrum development team’s responsibility to manoeuvre their tasks in the most efficient way so that everything is completed or ‘done’ by the end of the timebox.  If they are not effective at doing this through lack of self- organisation and collaboration, they are effectively allowing space, or ‘waste’ to form between their shapes.   Obviously, there are times when the sprint goals are threatened, such as when complexity is underestimated, or there is unexpected absenteeism.  This is fine.  It happens.  All the team need to do is continue to play their sprint Tetris well.  They can remove some stories, concentrating only on what can be completed, and continue to manoeuvre those tasks efficiently for the remainder of the sprint. So the moral of the story is, Space is waste!

The new A-Bomb: The ‘Agile’ Bomb: dropped by Agile Agent Bull

Beware of Agile Agent Bull.  He is armed with little knowledge and is dangerous.  He presents a great risk to your Company and can cost you thousands…

Be sure you recognise an Agile Agent Bull as soon as you encounter him.  He can take many guises, and may take a stealthy attack by using trusted charm offensives, like supplying your teams with endless donuts and squishy brownies to keep everyone sweet and cover up his incompetence. He may strut about with a cool air of confidence in an attempt to deceive the team into believing he is experienced.   Do not be fooled, these are rehearsed tactics.  BE STRONG! You must resist.  The cost of not outing Agile Agent Bull early on is much more expensive than a whole year’s supply of Krispy Kreme.

What can happen if you have an Agile Agent Bull in your organisation?  Well the impact can be literally nuclear because the aftermath of an Agile A-bomb can take a company months, even years to recover and pluck up the courage to take on another ScrumMaster.  Agile Agent Bull is a liability and we must engage our Intelligent Teams (IT) to seek out the enemy before the A-Bomb is dropped.

What’s Agile Agent Bull’s profile?

1)      He can talk the talk, but can’t walk the walk. Bull by name, Bull by nature.  Agile Agent Bull tells everyone he is a Certified ScrumMaster, and that he knows about Scrum and Agile.  Yet, when the team ask what they should do in terms of process in a certain situation, he doesn’t have a clue, or worse, gives some terrible, inappropriate direction. A direction that could cost the team dearly. He doesn’t know what he is doing. A ScrumMaster is an expert and knows what he (or she!) is talking about.  They can be asked anything and will have the knowledge to know how to deal with the question at hand.

2)      He can’t make good decisions.  The team need a strong ScrumMaster to turn to when they don’t know what to do in terms of the Scrum process.  As an expert, the ScrumMaster must be able to evaluate the situation, and know how to use Scrum to help the team get through.  He makes great decisions based on what is best for the team.

3)      He shies away from leadership.  Agile Agent Bull is weak.  He doesn’t lead the team and leaves them to their own devices.  He doesn’t tackle threats to the team such as a rebellious little scamp on the team or identify sloppy self-organisation.  He doesn’t have the tough conversations with managers.  He is a wet blanket.

4)      He is a bad facilitator.  He lacks the ability to add value to Scrum Ceremonies.   He lets the stand-up go on for half an hour and allows other meetings to constantly drift off-topic, making long meetings longer.  He does not hold quality retrospectives, impacting the team’s ability to continually improve as a learning team.

5)      He lacks discipline.  He spends his time avoiding matters rather than thinking of ways to tackle them.  He does not protect the team and doesn’t champion Agile to change the culture of the organisation towards its approaches.

Be warned!  Agile Agent Bull is out there.  Be sure to recognise him and diffuse his ticking A-Bomb.

One Love, One Backlog

Is it ever acceptable to run a project that is maintaining multiple backlogs? The answer is simply, no, it’s not acceptable, and you should see it as an impediment.  The reason being,  if a separate backlog is created for things like tech debt and bugs, or even a different part of the project’s functionality, each of these additional backlogs will have their own ‘top’ priority. So, how can you be sure which ‘top priority’ really is TOP PRIORITY?

As a Scrum Master, you can facilitate the necessary meetings to agree on how the issue can be addressed.  It may take some time to do this, as there may be some conflict around which PO or stakeholder’s backlog item is ranked highest once the backlogs are consolidated, but as long as Business Value and Return on Investment play a rational part in these discussions, the outcome should be that you have one prioritised backlog that all your teams are working from.