Blog

Jython Under Tomcat

February 25, 2019 admin Leave a comment

A little something different this post, something a little closer to my day job, which is as a developer.

Here I will go through how to configure Jython to run under Tomcat.
I have done this on an AWS instance, but because it is java based, it can be done on Windows and Mac just as easily. In fact, at work, I did this under Windows.

So, here is how you set up Jython to work under Tomcat.

Install Tomcat normally
Under the webapps directory, create a directory for your webapp. In this case, I’ve called it jythonTempate because I use it as a template for my apps.
Under jythonTemplate, create 2 new directories, WEB-INF and META-INF
Under the WEF-INF folder, create a lib directory
Download jython-standalone.jar, the latest version can be found here, and place it in the WEB-INF/lib directory.

This library will be loaded into memory when the tomcat application starts.

Creating The Servlet

Jython servles work by means of an intermediate Java servlet known as PyServlet. This is the servlet that Tomcat runs Jython servlets in.
Now we need to tell Tomcat to invoke the PyServlet whenever it gets a request for a resource with *.py. We do that through the web.xml file.

Under WEB-INF, create a file called web.xml with the following content:

<web-app>
    <servlet>
         <servlet-name>PyServlet</servlet-name>
         <servlet-class>org.python.util.PyServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
         <servlet-name>PyServlet</servlet-name>
         <url-pattern>*.py</url-pattern>
    </servlet-mapping>
</web-app>

This registers the PyServlet and matches it with any resource that matches the pattern *.py

Next we create the Jython Servlet. Create a text file called jythonTemplate.py under the jythonTemplate directory.
Give it the following contents:

import sys

from java.io import *
from javax.servlet.http import HttpServlet

class jythonTemplate(HttpServlet):
    def doGet(self, request, response):
        self.doPost(request, response)

    def doPost(self, request, response):
        toClient = response.getWriter()
        response.setContentType("text/html")
        toClient.println("<html><head><title>Servlet Test</title></head>" +
                    "<body><h1>Servlet Test</h1></body></html>")

if __name__ == "__main__":
    JS = jythonTemplate()

Start tomcat and go to the URL of the server. For example, if you are on localhost : http://loalhost:8080/jythonTemplate/jythonTemplate.py
You should see a similar output like this:
You now have created your first Jython servlet.

Adding the Python Libraries

Jython/Python has a rich set of libraries that you can use within you Tomcat application, but before you can start using these libraries you need to make them available to your application. To do this,

Download the jython installer from the link above.
Under WEB-INF create a directory called lib-python
Unzip the jar file and copy the contents of the Lib directory to the lib-python directory. It doesn’t matter what name you use for the lib-python directory, it just needs to be in the WEB-INF directory. All these files load into tomcat under this directory.
You now have access to the python library to use within your servlets.

Set the Default Application

To set the default jython application to be run when you go into the top level http://localhost/jythonTemplate URL, you need to modify the context.xml.
This file needs to be created under the META-INF.It contains the following content:

<?xml version="1.0" encoding="UTF-8"?>
<Context anitJARLocking="true" path="/jythonTemplate/jythonTemplate.py"/>

You may have to restart tomcat for the changes to take effect.

Generally, if you modify a python servlet, the changes take effect straight away, but if you make a python library file. It generates a class file on load and this is what is loaded into tomcat. When I make these types of changes, you still need to re-load the application or restart tomcat.

I do a lot of work with SoftwareAG’s WebMethods, I am in integration. So what I have done is write a library in Java that allows me to execute webMethods services through Java, but since I also use Jython, I can execute these services in Jython now as well.

So, why Jython? Especially given that the version is 2.7.1, which the python version will cease support soon? Well, because I like the python language. I find it easy to use than Java.
I need to play around a bit more and see if I can use Flask to create applications. But for now, I create simple tools that help me with my day to day work. I also at some point want to see if I can replicate this using JRuby.

Please let me know in the comments if you found this useful.

Blog

What does Scrum say about…

February 11, 2019 admin Leave a comment

I’ve been reading Agile forums and there have been a couple of ‘What does Scrum say about..” questions and I thought that this would be a good topic to discuss with my opinions.

The questions were “what does scrum say about SRS (Software Requirement Specifications) documents? And “what does Scrum say about Unplanned work?”

To put it simply… absolutely nothing!

Scrum at its core, as I understand it, is a basic process (a framework you can build upon) for a work feedback loop. It is not specific to software development, although I acknowledge that it’s roots are from there, but in its current form, it has nothing to do with software.

What is a feedback loop? It is one where a portion of the output feeds back into and controls the input.

If you put a microphone close to a speaker where it’s feed comes out of, you will soon hear what happens in a feedback loop.

So what is a work feedback loop? It is where the results of the work feed back into the next lot of work. In Scrum, this is done through the Retrospective. Some of the leanings for the previous sprint feed back into the next sprint in the form of an action item and leanings. You also have mini feedback loops through the daily Scrum where the work from the previous day determines the work for the next day depending on he achievements towards the goal.

The thing is, with feedback loops, the sooner you get the output directing the input, the better you can make adjustments. Think of your thermostat. If it increases the temperature, but it take half an hour before it registers the temperature, well, things are going to get quite warm. Then when it cools down, things are going to get quite cool before the heater kicks in again. The same with work. If you can get that feedback loop in such a way that you can make adjustments to see if the decisions originally made on what to work on, then you can get those leanings faster, and adjust future decisions accordingly. If on the other hand, you do not have a feedback loop, even though you get stuff done, you don’t know the effects. You could happily be working towards going off a cliff, or climb to new heights. but you won’t know till you get there.

In Scrum, the feedback loop is used to work towards getting better. You make adjustments towards better quality, towards being better. Scrum itself doesn’t make you better, or provide a better process – but it helps you make adjustments through the feedback loop towards that better process.

So, going back to the original questions, and others similar – what does this have to do with them?

Well, you have to ask yourself – does the thing you are asking advice on, be it Software Requirements, or handling unplanned work help you get that feedback loop working quicker? Does it help you get better quality?
In the case of Software Requirements, well – you spend a lot of time writing them. Weeks, months. Does it help you get feedback on those requirements quickly to determine if the requirements are right in the first place?

In the case of Unplanned work, does it help or hinder the work your already working on, on getting feedback on that?
In other words – is unplanned work good or bad? I tend to think it is bad because it interrupts, which causes context switching which causes things to slow down – but I understand that unplanned work occurs. So, what I do is try to find out the causes of unplanned work, this is the feedback part. Then try to find ways of either eliminating the cause of that unplanned work – for example, defects, or finding ways to get more notice of that unplanned work. Sometimes, the unplanned work has been in discussion for a while – you just get notified about it at the last minute.

I see the goal of Agile not to be faster, cheaper and all that. Its goal is to increase quality, while increasing the feedback to make adjustments to increase quality. Being faster, cheaper is just a happy unintended side effect.

Blog

When you execute the plan perfectly – How do you improve?

February 2, 2019 admin Leave a comment

Today (Saturday) we had the go-live of a medium sized project that had been going on since September. The project has been run as an Agile project using the SAFe methodology.

The whole process took about 5 hours from start to finish, my job (as a developer on the project) was to do the cutover for the integration piece. The integration side had been deployed to production weeks ago, and just been laying dormant waiting for the config change to switch on, which I did today, but I also had to manage traffic to the end point systems which also had deployments. Then there was the verification and so forth.

Plan executed flawlessly, and we even went home an hour earlier than planned.

Success!

So, a few hours later, after I had time alone to think, I did a personal retrospective. You would think that since the plan executed perfectly (well almost) that there wouldn’t be much to do for a retro. Even a personal one. This got me thinking about Lean, and where I learned that if you don’t see a problem, your not looking hard enough. So, how do you look for problems when there weren’t any?
I turned things around – instead of looking for problems, look at ways that I could have got my Saturday back! How can I eliminate the need for myself.
So what did I do? I started looking at the tasks that I had throughout the day. If I had the time before the go-live, what would need to happen so that I would not need to do those tasks? Could I give control to the end point systems to pause traffic? How would I go about doing that? First problem! What does it accomplish if it was done? It would mean that I would have been able to come in later in the morning instead of first thing as I would not be needed. Does that move me closer to accomplishing the goal of giving my Saturday back? Well, no as I’ve done the task – but if it had been there – then yes! also, would it have made our cutover process better overall? Yes! therefore it is something we should look at implementing.
Onto the next task. I went through this process again and again.
Then I noticed something – I had the wrong goal! The goal should not be “get my Saturday back”, the goal should be “get everyones Saturday back”
In my opinion, this is close to system thinking. Localised optimisation (in this case – me gaining my Saturday back by offloading some tasks to the end point systems implementers) helps me, but it doesn’t help my fellow team mates. We have to look at optimising things so everyone benefits for the whole system, In this case the go-live, benefits.

So the next time a plan executes flawlessly – or near to, during the Retro or even if you don’t do Agile or Retros, do a personal one. Turn things around. Look at ways to maybe reduce the time to implement by half, or eliminate the need to manual intervention (ie, so your not there). Look at what needs to be done to accomplish that. You won’t be able to execute everything, but pick just one thing. If it moves you closer to an honourable goal – then look at implementing it no matter how little it helps. Every bit counts.
Remember though, if you find something and it just sits in the backlog with no one touching it, implementing it – then it does absolutely nothing.

Blog

Santa’s Scrum Adventure

December 5, 2018 admin Leave a comment

With every year the Christmas cheer would just get bigger and bigger.
Santa had troubles keeping up, his elves had to get quicker and quicker.
Then one night while he was filling his tum,
He found the answer, it was Scrum!
They brought in both Ken and Jeff, they both were a Scrum Master.
Santa was of course the one and only Product Owner.
The elves divided themselves in teams between 3 and 9.
They started working in sprints from 1 month down to 2 weeks at a time.
Sprint would start, they’d plan their tasks
First Masks then little Red carts.
During the StandUps,
Santa would interrupt
And Ken would say “No No!”
They almost had to cancel the sprint when Santa wanted to make Yo-yos.
They reviewed each sprint, it was a hit
The toys were the best made ever.
The retrospective was very selective on what they could do better.
They repeat and repeat till Christmas Eve getting better and better each turn
By then Rudolf had become the next Scrum Master intern.
This Scrum is great,
Let’s haul the freight
To all the boys and girls.
Christmas was saved,
The change was braved
Next year we’ll give Scrum another whirl.

Blog

How Our Board Works

November 12, 2018 admin Leave a comment

You have probably seen variations of the Scrum/Kanban board, and from looking externally, ours is no different, but I thought it might be a good idea to go through how our board works. A practical example as looks can be deceiving.

To give you an idea of our circumstances, we are a BAU team. So we do both support and development work. We are a long lived team, but can be deployed to projects individually.

The Basic Board Layout

As you can see from our board, we have a few more columns more than the “To-do, Doing and Done”.
Each column represents a step in our development process.
Analysis – Analyse the card to determine what work needs to be done.
Build – The actual development step.
Test – Testing obviously
Review – where we get the code peer reviewed
Deployed – where it is deployed into production and finally
Done – the card is complete.

This should be obvious to anyone who has done development work before. Nothing new here.

You may also notice that we have sub-columns. WIP and DONE (Yes, multiple Done columns!).

What does this mean, well.
WIP – Work in progress. This is where when a card is actively being worked on lies.
DONE – When you finish working on the card in that process, you move it to the DONE column.
What this does is give you a visual indicator on what cards are actively being worked on, and what cards have been completed in that process. Then, the person who performs the next process (Not necessarily the same person), when they start working on the card, they move that card from the DONE column to the WIP column of their process.
So for example, John is a BA doing analysis on a piece of work. He takes the card from the backlog, moves it to the WIP column. The card stays in this column until he completes the card. It may stay there an hour, it may stay there a week while he works on other stuff (I’ll get to this scenario later). Either way, you can see what is in progress.
Once John is finished his piece of work, he places it in the DONE column. Now, Jane is a Developer. When she has spare capacity, she will take the card from the DONE column under Analysis and move it to the WIP column of Build where she works on it. The card itself then follows the processes through the life cycle until it is completed and deployed into production.
Fairly simple.

The next thing you may notice is that we have our projects listed in the backlog. Here we put the next lot of cards ready for work. We have divided things into projects because… that is how we work. It may not be right, but it is the current process. I’ll get to this later.

Another thing you may notice is the colour dots across the top. Each colour is a representation of the process. I’ll get to this later. Now I will explain how the cards work!

The Basic Card Layout

Now, our cards are quite simple. Across the top, we have a header where we give the relationship of the card to what it is for. In this example, I have given the header “Retrospective” as the card may have been related to a task determined during the Retro.
The next segment is the Description. Here we give a short description of what the card is for. In our team, we do not do stories, but we can – but only when they make sense. So far we haven’t needed to.
Then we have the date the card was created, the sizing Small, Medium or Large and who the card is assigned to.
I hear some Agile people saying that this is a no no, I agree, but that is how we work. At least for now.
All this is pretty standard.

We also have different colours for the cards themselves. White is BAU tasks, Red is unplanned work, Blue for Internal Team projects, Green for External Business projects and Yellow for Personal Development. Therefore from a visual perspective, you can see what everyone is working on.
Unplanned work – Red – is a special case. This is work that has skipped the backlog and become urgent. It may be an unplanned request from the business, it might be a bug. It is basically anything that has disrupted the flow of cards and caused someone to stop what they are currently doing and do something else.

But, now we get to the interesting part – the coloured dots.Each dot has a meaning.

The Red dot represents a card going backwards. Lets say that a defect was found during testing. The card then goes back to build to fix the bug. A red dot is then added. If the card fails testing again and goes back to build, then another red dot is added. If the card rolls back after deployment, another red dot is added. The idea is that we get a visual representation of troublesome cards. The idea is not to discipline the person causing the problem, but to identify the problem in the first place and then look at ways at preventing it for similar work in the future.

The other colours, you will see represent the process steps.
For each day that a card sits in the WIP column of the process, a dot is placed on the left side.
For each day that the card sits in the DONE column of the process, a dot is placed on the right side.
We just use whiteboard markers to place the dots (I have multiple colours!) instead of stickers. Stickers can be too big.
What this shows is how long a card is in each column. This can help identify bottlenecks in the process such as resourcing constraints.
Basically, if a card has measles, then it is sick.

Now, on the back of the card,
we have a section for notes. This could be acceptance criteria, it could be blank. The option is there.
Then at the bottom of the card, we have replicated the columns of the board again. Here we record actual work time. So time actively working on the card. We do not assume that if the card is in the WIP column, that it is actively worked on. This is the case when someone has multiple cards open. They may be working on something but it may be blocked (which we indicate with a tag labeled “Unblock Me!”) waiting for something.
When combined with the left hand side dots, we can get a ratio of actual work time vs lead time.

Say you worked on a card for 20.5 hours as indicated above. But the card was in WIP columns for 6 days, 48 hours. Our ratio is 20.5/48 which gives us a 0.43 ratio. So what this means is that the next card of similar size (hence why we add sizes to the cards) If we guess that it will take d days of work (16 hours), we can expect it to be completed after 37 hours. About 4 days. The actual time again is recorded in a similar manner and the variation is then graphed. This can then be used for reference for future estimations.

The cards themselves are placed on the whiteboard using magnets. I got a couple of those magnetic calendars you get in the mail to place on your fridge and cut it up to about 1cm or smaller squares and used blu-tak to attach them to the back of the cards. It makes it simple to move the cards and so far we haven’t had many cards fall off. Much better than post it notes.
The cards themselves are printed out on a colour laser printer to get the different colour cards and we just mark them up with pen. The cards are quite small. About 4cm x 5cm.

Analysis

This board itself does not make you Agile. Lets have no delusions about this. What it does do though is help get you Data!
Data to help determine where the bottlenecks are, data to help with estimation. Data to determine if a change in the system has any affect.
Having a board itself does not help you be agile, it just helps you gain a bit more understanding on how you work. Its what you do with that understanding, that data and use it to progress towards agility that determines if you are agile or not.
Do nothing with the data other than make pretty graphs, and you are changing nothing.
Using the data to guide your decisions, that is where the real power is.

Now, I should mention that I do not force anyone to follow this process – except myself. I have left it up to the individual team members to determine the value, but as a fellow developer, I can at least go to my manager with more solid backed by data information than just doing a finger in the air guess.

I would also like to mention that you should not follow our board like for like. Use our board as an example, but iterate and analyse your processes to develop your own methods.
Our board is constantly changing an how it works now is not how it may work in 6 months time.
For example, I would like to try reducing the number of projects, set work in progress limits, try to remove the assignment of tasks to individuals and make it more team based, but that requires a culture shift which is pretty hard to do overnight. It is my intention that over time, as we identify problems using the data from the board and figure out ways to solve those problems, that we get better.
Yes, we could implement an existing framework such as Scrum, but then we get into the culture problem again. Who knows, we may figure out Scrum ourselves, or figure out some other method. My intention is that it is for the team to explore and not for me to dictate (not that I could anyway).

Blog

Scrum Guide Decomposition Part 4

October 27, 2018 admin Leave a comment

This is the third part of the Scrum Deconstruction. You can find part 1 here, part 2 here and part 3 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.

Here I share in the hope that someone finds it useful.

Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.

Sections in Black will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.

Sections in Red will be the negative aspects that I see, or have been told, read or anything else negative. Sometimes these will sound silly (and probably are) as it I find it difficult to find negative aspects, this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.

Side Notes are in green.

Now, lets get on with the deconstruction.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the Product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

The Product Backlog is just a list of items. That list doesn’t have to be user stories. It also doesn’t have to be in Jira.

It can be in excel, cards, a word documents, hand written on paper. It isn’t specified. The practices of how the Backlog is kept is independent of Scrum.

It is the single source of requirements. That means that if someone wants to do something, it must go on the Product Backlog, and since the Product Owner is in charge of the Backlog, it must go on with their blessing.
That means that even if the CEO wants something done, they don’t go directly to a developer, they go to the Product Owner. This means that the Product Owner position is one of respect. No someone who’s a managers lacky.

The list also needs to be ordered so that when the list is looked at during planning, or if the development team finishes the Sprint Backlog early, it is easily known what is the most valuable work is.

What if everything is of equal value. I’ve had that before!

Then nothing is of value. This is an antipattern. The Product Owner wants everything, so everything is of equal value. This is then used to rush developers. Which leads to shoddy work as the developers try to complete everything in the Sprint. This then leads to Technical Debt and problems in the future.

There is always something of high importance\value. This needs to go first. Then the next valuable piece of work and so forth.

A Product Backlog is never complete. The earliest development of it lays out the initial known and best understood requirements. The Product Backlog evolves as the Product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a Product exists, its Product Backlog also exists.

When you first start, you do not need to work out everything initially. It will all change anyway as new things are learned. You cannot know everything up front. What you know initially, start working on. Work out the rest later. The later you can delay decisions, the more time you will give it to change. So that when it get time to do the work, hopefully – not always – the changes will be minimal.

The Cone of Uncertainty

As you get closer to the finish of the work, you start to get an idea of what the end will look like. At the beginning, you don’t know what problems you will face, therefore in order to better predict the outcome, you need to work in small goals.

You reduce the unknown to a short interval. Deliver to that interval and at least that small sections is known. Yes it can change, but you are delivering value sooner.

This is why the Product Backlog should be dynamic.

Even though the “Project” is complete, changes, bugs, new features, unfinished work still exists. These are stored in the Product Backlog as well so that they can be worked on at a later date, when there is more time or budget.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the Product in future releases. Product Backlog items have the attribute of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

The Product Backlog contains everything needed for the Product. This includes DB, servers and other non-functional as well as functional requirements.
Each item should have a:

Description : These tend to be in the form of stories
As a …..
I want ….
So that ….Yay!

but they do not have to be. They can be a header, a paragraph, a video, drawing. The important thing is that they have context to how the item fits in, and convey enough information to know what the work is.
Order : Generally what is needed and most valuable at the top, least valuable at the bottom. Make it easy for the team to know what to work on without them having to ask. Also think, if you were to run out of money in the next Sprint – what would you want most!
Just don’t like I mentioned above ask for everything.
Estimate : So you have a guide as to how long or how much effort the item will take.
Note : Scrum does not specify the method of estimation. You can use Story Points, T-Shirt sizes, animal sizes, or dare I say it, time.
There are reasons why you should not use time. I won’t go through them here.
Value : This could be in the form of ROI (Return on Investment, time saved etc. This helps give context as to why the work is being done.
Some companies include ROI, even in non-Scrum projects. The problem is that at the end, the ROI is never verified. You never know if the value is realized or not.
This is not good.
Test Descriptions : These help the Developer know that they have built the right thing. Again there are many forms, but the more detail included, the better an understanding the Developer has. Tools like Cucumber, Fitnesse, Concordion can help automate verification by allowing tests to be described in English rather than code.

As the Product is used and gains value, and the market place provides feedback, the Product Backlog becomes a large and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Change in business requirements, market conditions, or technology may cause changes in the Product Backlog.

The only way to know if the Product will be useful is when it is used. Real hands on. Not labs, not trials, but real people using the product in anger.
You will then know its short falls. The fixes, changes, extra functionality then gets added to the Backlog.

A ‘Product’ is a long lived thing unlike a ‘Project’. Requirements evolve, there is no end until the Product dies for whatever reason.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to decrease the upcoming work on the Product. A Product Backlog attribute that groups items may be employed.

One Product Backlog, one source of value. Everyone works togehter to get the most value sooner.

Product Backlog refinement is the act of adding detail. estimates and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of the Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items are updated at any time by the Product Owner or at the Product Owners discretion.

Product Backlog refinement is where you go through items in more detail. Break down the items to smaller pieces of work. Get acceptance criteria added. Work out in detail what needs to be done for each item. Not too much detail, but just enough. How much is enough? You have to work that out by trial an error. There are no easy rules.
Refinement should not take more than 10% of the time, but you can take less.

More meetings, when do you get the work done?

Refinement is done anyway, even in waterfall projects. Its more hectic and ad-hoc when you do not specify a time.
This is a requirements gathering process. Rather than spend a whole heap of time up front, you are doing this during the development.
For Developers, this may seem to be an issue. BAs do the requirements gathering traditionally. Put them together and hand them over to the developer for coding.
In Scrum, there are no BA roles. You, the Developer are the BA, the Tester and the Developer. Look at it as an opportunity to learn. Not a “Not my job” situation.

Higher order Product Backlog items are usually clearer and more detailed than lower order ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can be reasonably “Done” within the Sprint time-box. Product Backlog items can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of Transparency through the above described refining activities.

The closer you are going to work on an item, it needs to have more detail. This makes sense. Why would you add more detail to an item you won’t look at for some time, while neglecting upcoming work?
Get the items to a point you can start and finish the work in a Sprint. Don’t do half the work now and the other half next Sprint. Treat the work as if this Sprint is you last. Any subsequent Sprints (even planned) is a bonus. At least during the planning.

This is a definition of “Done” which we will get to later, but should there be a definition of “Ready”?

The Development Team is responsible for all estimates. The Product Owner may influence the Development team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

Have you ever been in the situation where a manager gives you a piece of work, expects it to be done in a few days, instead it took you a few months (I’m not talking Scrum here – but traditional development)?
This statement is to give Developers the ability to say it will take a few months. Not a few days. They should know – they are doing the work.

Monitoring Progress Towards Goals

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with the work remaining at previous Sprint Reviews to assess progress toward completing the projected work by the desired time for the goal. This information is made transparent to all stakeholders.

This is giving the description Burndown chart, without explicitly saying Burndown Chart because it limits thinking of other ways to describe the data. Some of which are mentioned later in the guide.

This is basically the sum of all estimated work remaining compared to the previous sum. Compared to all previous Sprints you get a trend over time on how work progresses. This can be used as a guide to determine when the work will be completed.

Various projective practices upon trending have been used to forecast progress, like Burndown, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making .

Various examples are given to represent the data. What this data shows is a rate over time think of this rate as showing your speed on an odometer. If you are on a freeway, your speed is 100kph. On a suburban road it can drop to 50kph, a school zone and it’s 40kph. This is the known limits, and estimates can be derived data, but what happens if there is an accident on the road, road works, traffic, a special event? Your rate changes, your estimated time of arrival (delivery) changes. These need to be taken into account – but after they occur. A good GPS system will do this for your journey. You have to do the same thing for your journey in doing he work.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next increment and the work needed to deliver that functionality into a “Done” increment.

A Sprint Backlog is:

Selected items
A plan for delivering of the increment and the Goal.

It is a forecast, not a contract.

I have heard Scrum Masters mention Commitment to the work. This language I think is dangerous. It can be taken as ‘hell or high water, this amount of work will be done’.

this can lead to late nights, long hours, working weekends to complete an illconcieved Sprint Backlog. this is not what we want. A Sprint is a timebox – not a deadline and we are trying to measure the ‘rate’ of work at a reasonable pace.

NOT ‘get all this stuff done before the Sprint Deadline’

We can get booked for speeding on the road. Scrum Masters should be booked for “speeding” their teams (driving them too hard) otherwise just like an engine, they will burn out.

The Sprint Backlog makes visible a,, the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes one high priority process improvement identified in the previous Retrospective meeting.

This last statement of including at least one improvement is key to getting better. Unfortunately many teams do not do this, or do not see it as a priority. Thus it gets dropped off.

High Performance teams already do this as mentioned by Ken and Jeff when this version of the Scrum Guide was released.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the daily Scrum.
The Development Team modifies the Sprint Backlog throughput the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

Unlike Waterfall, with Scrum you do not work out everything up front. You are not supposed to. How many times have you worked on something only to find a detail that you forgot, didn’t know about, had a problem you could not solve and had to figure out a work around? Scrum takes these things as fact. Shit happens. So don’t plan too far ahead because it is all going to change anyway. Just plan enough to get by for now and a little ahead in the future. We learn as we go.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change the Sprint Backlog during the Sprint. The Sprint Backlog is highly visible, real-time picture of the work that the Development Teamplans to accomplish during the Sprint, and it belongs solely to the Development Team.

As the Development Team works, things missed get added to the Sprint Backlog, or something drops odd in the Sprint Backlog back into the Product Backlog.

One thing about Agile is that we try to minimize the work done. If something is no longer needed – drop it. Don’t do it anymore. Makes sense right? It is best to find out as early as possible if something is needed so that you do not waste time even just thinking about the redundant item. It’s amazing how much work is done that is not required.

The Sprint Backlog should be visible to all. This is why you can see Scrum boards. It’s a visible way to see the work.

By making it visible – everyone can see the progress. Nothing is hidden.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks the total work remaining t least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Much like the Product Backlog, remaining work can be tracked, checked and determination of completing the work be done. This should be done at least daily, during the Daily Scrum. This is through moving the cards on a Scrum wall – that is if you use the Scrum wall. What I have seen is that what is missed is checking if the Sprint Goal is likely to be accomplished.
This statement again disproves the “What I did yesterday, what I will do today, any blockers” statement. These should be discussed and answered during the daily scrum, but they are not the only things that should be done during the Daily Scrum.
Again, this emphasises that this is a responsibility of the Development Team. The Development Team are masters of their domain.

Increment

The Increment is the sim of ll the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new increment must be “Done” which means it must be in a usable condition and meet the Scrum Team’s definition of “Done”. An Increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The Increment is a step toward a vision or goal. The Increment must be in usable condition regardless of whether the Product Owner decides to release it.

Basically an increment is all the work done to date that has been fully completed and is in a state that the Product Owner will find usable to some degree.
By Definition of “Done” which is discussed later, it mast be code reviewed, have error handling, follow standards, be tested and be at a point ready for release. By doing this up front – even for work that is not i a fully complete state, i.e. still has many months left to bring it to full spec, you:

Get feedback sooner. If left till fully ready after months, without checking you run the risk of not making what the client needs or wants.
If budget runs out, the client still has something usable. Even after the first 2 weeks.
It forces you to think in smaller chunks of value rather than just going for the whole thing.

The Product Owner is the best person to know when to release as they know when the product will give the most value to users and stakeholders.
By having the increment in a “Done state, there is no reliance on “fixing” bugs or any other trepidation before release as they should have been looked at beforehand.

Artifact Transparency

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions are flawed, value may diminish and risk may increase.

Have you ever worked on a project where you know that the whole thing will be a mess, you tell the Project Manager that it will last less than a day before it completely fails, but they release it anyway because the Project Manager told Management everything was O.K.

Ever been in a project where everything was green up until a week before release?

These problems occur because information is hidden. It usually ends badly and it occurs so frequently that it is considered normal.

Scrum relies on everyone knowing everything and by everything, I mean the correct information. No lying or bending the truth. That way good decisions can be made.

But for this to happen, there must be an environment where it can happen without repercussions.

i.e. There must be TRUST!

The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artefacts are completely transparent. There are practices for coping with incomplete transparency. The Scrum Master must help everyone apply the most appropriate practices in the absence of compete Transparency.
A Scrum Master can detect incomplete transparency by inspecting the artefacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

It is the Scrum Mqsters job to try to teach the Product Owner and the Development Team to be transparent.
Some technologies are:

Kanban Board/Scrum Board
To visualize the work.
Gather Metrics
– Length of time of a ticket/item not worked on or
Retrospective Techniques

Sometimes by just listening to the Team the Scrum Master can get a sense that something is wrong.
For example, mumbles about work, management, hiding stuff from the Product Owner.
The Scrum Master must help the team expose these to they can be addressed.

The Scrum Master’s job is to work with the Scrum Team and the organisation to increase the Transparency of artefacts. The work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

The job of the Scrum Master is not an easy one. If done right.
There is so much resistance to true agile. It is much easier to follow the “Process” and be ignorant of the reasons as agile shows problems. It is far easier to hide and ignore those problems.

The road to transparency if long and arduous. It is a journey without end, which is fine as the journey is what is important – not the destination.

Definition of Done

When a Product Backlog item or an increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the Product Increment.

Have you ever thought something was done only to find out that there was a requirement . or a portion of the work that needed to be done to complete the piece?
Have you ever built something only to find out that it wasn’t what the customer or end user had in mind and have to start all over again?

This is what the “Definition of Done” is for. To make sure every one is on the same page, and has a shared understanding of hwat needs to be done to complete the work.

Because everyone has their own understanding of a “requirement”, the customers understanding needs to be “extracted” from the customers brain and “implanted” into the development team. My favorite method of doing this is through examples.

Stealing from Gojko Adzic’s book “Specification By Example“…

Lets say that the customer has asked for a “10 point star”. A simple requirement.

So… you produce the followiing…

Is this correct? Well, that is up to the Customer. In this case, the customer says “No, go back and try again!”

Racking your brain, you have no idea what the customer is asking for. So you ask them to sketch it out.

Huh? Thats a 5 point star!

No, says the customer, its 10 points!

Ah! you now say. I know what you are thinking!

A simple example of hat is expected can enlighten all on what is required.

This will then reduce re-work and mistakes on misunderstandings.

Other things can include having a list of what needs to be done. Such as…

Tested with Automated Tests
Following coding standards
Documentation complete
Meets acceptance criteria
Code reviewed
No known defects
User acceptance tested
even
Migrated to production

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver increments of potentially releasable functionality that adhere to the Scrim Team’s current definition of “Done”.

This means that you select items from the backlog that produce some functionality that is useful.

Not half of a piece of work one Sprint and the other half the next Sprint.
“There is no next Sprint!”

The next Sprint should be considered a bonus that is not guaranteed.
Therefore select items accordingly. Reduce scope if need be.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an Increment is part of the conventions, standards or guidelines of the development organisation, all Scrum Teams must follow it at a minimum.

If the Product Owner chooses to “release” the “functioning” product, this means that value is returned “sooner” than if the project was complete.

It also means that any learning from the product in production can be done sooner, thus determining if the work was valuable or not. It is not, stop working on that feature and try something else. If it does – continue working on the feature.

If the Product is “good enough” then the Product Owner may choose to not continue with the rest of the project.
This is known as “chopping off the tail”. There is no use continuing as all required functionality is already delivered.

This is another reason – from a customers perspective to get things in use by the users ASAP.

Also, if the company has existing standards, incorporate them inthe “Definition of Done”, but review them regularly. You may find some no longer relevant or appropriate. A good place to look at this is a Retrospective, but that should not be the only place. You should do it during the Daily Scrum, Planning sessions etc.

Inspect and Adapt!

If “Done” for an Increment is not a convention of the development organisation, the Development Team of the SCrum Team must determine a definition of “Done” appropriate for the Product. If there are multiple Scrum Teams working on the system or Product release, the Development Teams on all Scrum Teams must mutually define a “Definition of Done”

IF there are no company wide or team wide conversions for “Done’, make your own. Call out what you want to make it happen to make sure you make a quality product.

Make sure that all Scrum Teams that work on the same Product share the same quality values and “Definition of Done”.

If you do not do this, you will find portions of the Product in non-working order or of dubious quality.

Its just common sense.

Get the Teams to decide their “Definition of Done”, don’t dictate it to them (unless it is an existing definition). If they define their own “Definition of Done”, they have buy in. They may get more engaged.

The Team may care more about meeting the “Definition Of Done”.

Each Increment is additive to all prior increments and thoroughly tested, ensuring that all Increments work together.

Each Sprints output builds on previous Sprints. This means that you need to make sure that past components developed still work. This means regression testing.

Agile won’t work easily with manual procedures. There just isn’t enough time. Therefore you need to automate.

Automated regression testing
Automated deployment

Basically, reduce the time ti takes to do stuff.

But don’t do it up front. Do it along the journey. That way you only automate what you need to.

Keep doing the improvement as you go along. That is the whole point.

As Scrim Teams mature, it is expected that their definition of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is standard for any work done on it.

The goal of Scrum is continuous improvement – not to keep the same pace, the same steady run. As you get better and stretch your abilities, your definition of Done should also evolve.

This may include:

Severity goals
Reviewed by legal
Penetration testing
Performance testing
Continuous testing/Integration/Delivery

and any other criteria that you may wish to include.

You can’t add this sort of thing until you get better, faster and more ‘agile’. Yes, I mean agile in the dictionary meaning – not as in the Process or Methodology.

End Note

Scrum is free and offered in this Guide. Scrum’s roles, events, artefacts, and rules are immutable and although implementing only parts of Scrum is possible, the result s not Scrum. Scrum consists only in its entirety and functions as well as a container for other techniques, methodologies, and practices.

Ok, for those that complain that you need certifications to so Scrum or to be a Scrum Master here is the proof that you do not need any of those things.
Scrum is free!
I remember about 20 years ago, you ha to pay to use the Rational Process to develop software. This is not the case with Scrum.

Also, those places that do “Scrum” but do not do Retrospectives or Daily Scrums/Stand ups – you are NOT doing Scrum.

Saying that, you an still not be doing Scrum if you follow the “Process” to the letter but ignore the underlying reasons for the process. Which basically is to get better. You get better by finding and fixing problems. Not by blindly following the process. The process is there to guide improvement actively over a Sprint, not organically as required whenever or every now and then through workshops.

Remember the beginning. Scrum is a framework on which to build improvement. Techniques such as Scrum Boards, User Stories, Scrum Poker, Story Points are not part of Scrum but still can be used. This is known as Scrum-and as opposed to Scrum-but where parts of Scrum are used.

Finally!

For those that are interested, as I mentioned in the first post, I have hand written the Scrum Guide and my decomposition. You can find a copy here. Fair warning, its a large 80+MB pdf file.

I started this a year ago when I decided to do this as part of my study for the PSM I Certification. Hopefully you have found this useful. Please let me know in the comments.

Blog

Scrum Guide Decomposition Part 3

August 25, 2018 admin Leave a comment

Well, that was a long hiatus that I didn’t expect. I usually write while my better half is at work, but she has been at home injured so I’ve been spending quality time with her until she is better.

This is the third part of the Scrum Deconstruction. You can find part 1 here and part 2 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.

Here I share in the hope that someone finds it useful.

Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.

Sections in Black will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.

Side Notes are in green.

Now, lets get on with the deconstruction.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Note : Its says “minimize the meetings not defined in Scrum, not exclude them”

All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

If you decide 2 week sprints. Stick to it, if you decide 1 week, stick to it. Some teams start to try different lengths when they first start. They may try 2 weeks, 1 week or 3 weeks, but once a decision is made on the sprint length, stick to it. Don’t chop and change sprint to sprint when it is convenient. Make it like clockwork.

I don’t work in 2 or 3 week blocks, I just do the work.
That’s ok, you don’t have to work in sprints – but that then isn’t Scrum. See Kanban.

The Sprint gives a regular time everyone knows and can thus work to. It will also force you to create something in the end. The pressure (not too much, not too little) can help foster innovation as you have to produce something.

The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

By fixing the maximum time, you prevent events from taking too long. It prevents them from going forever. It also helps focus the event to get the result. The sprint is different. It generally does not end sooner. For example, when the sprint backlog runs out prematurely. In this instance, you just pick up more work from the Backlog.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.

Look at each event as an opportunity to look back at what you have done and try to improve. Don’t just leave it for the retrospective.

These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Also too, if you treat the event as a “tick in the box” event, you reduce its effectiveness.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created.

You should create something useful. Not documentation, not a plan, not an environment. It can be small. Only do one specific thing in a narrow field, but make sure that it is usable.

Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous sprint.

There is no “a few days/hours of planning” before the next sprint. Everything is incorporated in the sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

When, with all that stuff do you actually work?

A Sprint does nothing outside a normal project. It just does it in smaller blocks. Rather than all planning up front, like in Waterfall.

During the Sprint:

No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
This is important. When companies start Scrum initially, they push to get things done quicker. When this happens, the first thing to go is quality.
But saying that, what is quality? You need to seriously look at what quality is and strip out the waste.
Eg. Documentation, having a 100 page spec that no-one reads or can understand is not quality
Having a concise document or diagram that everyone understands is.
Also have coding standards, etc well documented and be able to be verified. Nothing based on individual opinions.
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Scope is not fixed. It varies as you learn more.

Each Sprint may be considered a project with no more than one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

How many projects just produce documentation or specifications? Each Sprint is a self contained project. Just smaller. And no, its not quite like a small Waterfall project, its so much more.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress towards a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling A Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the Stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if the market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But due to the short duration of Sprints, cancellation rarely makes sense.

Sprints are cancelled if a radical change in Goal is required. Something seriously must be wrong if you cannot wait 2 weeks, or a month before you chop and change.

When a Sprint is cancelled, any completed and “Done” product backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog items are re-estimated and put back on the product backlog. The work done on them deprecates quickly and must be frequently re-estimated.

Knowledge fades fast. If you are working on something and have to put it aside for a period of time, then come back to it, you need to get re-acquainted with the work. That takes time. The partially done work needs re-estimation because you need to estimate how much “remaining” work needs to be done. Estimation is a tool to help you determine capacity, it is not a goal in itself to “complete” a certain amount of work, but a tool to help you plan how much work you can be done within a Sprint.

Sprint Cancellations consume resources, since everyone has to re-group in another Sprint Planning to start another Sprint. Sprint Cancellations are often traumatic to the Scrum Team, and are very uncommon. They are a waste.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum team.

Sprint Planning is time boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Eight Hours! Seriously. When do you get the work done!

Eight hours is only 1 day. That is 1/20th the time. A small price to pay to know what you are doing during the Sprint.

Sprint Planning answers the following:

What can be delivered in the increment resulting from the upcoming Sprint?
How will the work needed to deliver the increment be achieved?

Topic One: What can be done this Sprint?

The development team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum team collaborates on understanding the work of the Sprint.

The objective of the Sprint is some functionality that can be used. Something small, but useful. It may be incomplete, but still useful. The Product Owner needs to get what is in their head into the Developers Head with regards to the objective – not the solution. But – the whole Scrum team needs to work to understand.

This is different to standard practice where a Spec is handed over and everyone works to it. Specs can be interpreted differently. The idea here is to remove the different interpretations, remove the ambiguity to the goal.

The input to this meeting is the Product Backlog, the latest product increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

The number of items selected from the Product Backlog for the Sprint is solely up to the Development team. Only the Development Team can asses what it can accomplish over the upcoming Sprint.

The Development team has the right to refuse work. This is hard because most people want to please. The environment must also be safe enough for the Development Team to reject work. Therefore the Scrum Master should back the team and the Product Owner should respect the decision.

Contrary to current management where you get what you have been given.

Will never work, Management pushes.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum team crafts the Sprint Goal.

The whole team crafts the oal

Dev Team
Scrum Master
Product Owner

The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the increment.

The Sprint Goal is functionality to be delivered.
Eg.

Blogging product
- Be able to post a blog
Purchase Order System
- Be able to raise a purchase order
Ambiguous
- Make the CEO happy

Topic Two: How will the Chosen Work get Done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into the “Done” product increment during the Sprint.

The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The second half of the Sprint Planning is determining the Plan to produce a done increment. Remember the backlog items should not be a “solution”. They are required functionality.

The Development Team usually starts by designing the System and the work needed to convert the Product Backlog into a Product Increment. Work may be of varying size, or estimated effort.

Note. Estimation of “effort” not time!

However, enough work is planned during the Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

Note. No mention of stories. Stories are not part of Scrum. Scrum does not specify the method used to format items.
Work is broken down from large to small. One day or less is not just development, but everything including testing where possible.

The Development Team self organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

Self organizes, thus no one, including the Scrum Master assigns tasks to individuals. The Scrum Master must encourage the team to Self Organize.

Without someone directing, how will people know what to do? They will end up doing nothing!

That is why you need motivated people.

The Product Owner can help to clarify the Selected Product Backlog items and make trade-offs.

This is through negotiation. There is a certain amount of capacity that a team can handle. Over extend and something suffers. The goal is that the only thing that suffers is scope.

If the Development Team determines it has too much or too little work, it may re-negotiate the selected product backlog items with the Product Owner.

Too little – add more

Too much – remove some

The Development Team may also invite other people to attend in order to provide technical or domain advice.

But these people do not participate.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a Self organized team to accomplish the Sprint Goal and create the anticipated increment.

This is a feedback mechanism to let the Product Owner know the Development Team understands the requirements. It also forces the Development Team to put a strategy together on how to do the work.

Sprint Goal

The Sprint Goal give the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected product backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

The Goal could be the problem to be solved. It is basically something larger and more meaningful than just “the work”.
It also needs to be something that guides the developers decisions.

Sprint Goals should be S.M.A.R.T. Goals.

Specific
Measurable
Attainable
Relevant
Time Bound

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different then the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.

Daily Scrum

The Daily Scrum is a 15 minute time boxes event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

15 minute max – regardless of team size or Sprint size.
It is also not a status report.

The Daily Scrum is held at the same time and place every day to reduce complexity
This is a test question!
During the meeting, the Development Team members explain:

What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediments that prevents me or the Development Team from meeting the Sprint Goal?

Its stupid to have everyone standing around answering these questions – just do the work!

These questions do not specifically have to be answered on after another. The idea is that the team huddle together and work out what needs to be done to achieve the Sprint Goal.
I don’t care if you did the Health Check in the morning. I don’t care about the BAU work. I only care what helped make progress towards the goal. I don’t care if you did the Health Check in the morning. I don’t care about the BAU work. I only care what helped make progress towards the goal.

I have heard of a team that do the ‘Huddle’ to work out what they are going to do. Then the Scrum Master or Product Owner or Manager comes in and they then do the ‘Stand Up’. The ‘Huddle’ in this instance would have sufficed. The Scrum Master/Product Owner/Manager do not need to be involved.

Also note, that the Daily Scrum does not need to be done “Standing”. The “Daily Standup” is an expression from Extreme Programming. Not Scrum. If you want to do it sitting down, go right ahead, but saying that, by “Standing Up” you are in an uncomfortable position and more likely to have a shorter rather than longer meeting thus keeping within the 15 minute time-box.

The Development Team uses the Daily Scrum to inspect progress towards the Sprint Goal, and to inspect how the progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimized the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal, and to create the anticipated Increment at the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adopt, or re plan, the rest of the Sprint work.

Thus is a formal chance for the Development Team to do something if the plan goes haywire. Rather than continue blindly following the plan./ Do something about it!

Look – Re-assess – Re-plan – Implement.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15 minute time box.

A test to try to see if the Daily Scrum is a status meeting rather than a planning meeting is to tell the Scrum Master to piss off! But do this after the team is ready and understands what needs to be done.

Another test is to see if the Daily Scrum does not happen if the Scrum Master/Manager is not present. If they are not present, then the team does not feel that they need to get together to discuss the situation. Therefore they only see the Daily Scrum as a status update.

A Scrum Master enforces the rule that only the Development Team members participate in the Daily Scrum.

Daily Scrums improve communication, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the Development Teams level of knowledge. This is a key inspect and adapt meeting.

Daily Scrums may not work if everyone is doing their own thing as there is no need for collaboration. For example, Team member John is working on Project A. Jane is working on Project B. David is doing BAU work. Simon is working on an internal piece of work etc.
The question is, in this situation, which occurs quite frequently in business, are these people really working as a team?

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed.
During the Sprint Review, the Scrum Team and Stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next thing that could be done to optimize value.
This is an informal meeting, not a status meeting, and the presentations of the increment is intended to elicit feedback and foster collaborations.

This is a set time to get feedback from the stakeholders. With traditional development, stakeholders get feedback at the end of the project. This is usually too late for the stakeholders to make changes – at least without significant costs. Therefore the Sprint Review enforces the Stakeholders to review at regular intervals. It also does not mean that this is the only time that Stakeholders can give feedback. Feedback may be sought at any time. In fact the more frequent the better, but it should be at a frequency not to interfere with the work.

This is at most a four hour meeting for one month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time box.

Again another time boxed meeting. The Scrum Master is not the one running the show. They are the event planner. They make sure the event takes place. The Scrum Master helps everyone. Team members, product owner and stakeholders understand the purpose of the event. They may help direct the event, but the content is all Product Owner and Team.

The Sprint Review includes the following elements:

Attendees include the Scrum Team and Key Stakeholders invited by the Product Owner.

Key Stakeholders should be those who:

Pay for the work done so they can see where their money is going.
Those who will use the product because they will have to live with the result and thus should have a say.
Anyone else directly involved with the product.

You do not want people unrelated coming along like the whole company, you also don’t want walk ins, only those invited by the Product Owner. This is also not a Town Hall, keep the group small and relevant.

The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.

Full transparency here. No hiding half done work by not showing that feature. Show everything.
Done is based on the “Definition of Done”.

By showing what isn’t done, if stakeholders get angry, this will lead to the team “hiding” stuff. Hiding stuff means that the Stakeholders do not see reality and thus cannot make proper decisions. These decisions then affect the Development Team, it could be in the form of more work, new work etc before previous work is completed. The only way for the Development Team to “Catch up” is to work longer hours, or produce shoddy work. Neither of which leads to a good outcome.

The Development Team discusses what went well during the Sprint, what problems they ran into, and how those problems were solved.

More transparency. This time from the Development Team. By going through the development process, the Stakeholders can appreciate the work the Development Team went through. It also helps the Development Team take pride in their work. Rather than just showing what was done, they share the “struggle” they had to get the Increment done. A Developer that takes pride in their work is more likely to be engaged.

The Development Team demonstrates the work that has been “done” and answers questions about the increment.

Show the Stakeholders the progress and let them see so they can give better feedback. An even better method for the demonstration is to allow the Stakeholders to do the demonstration themselves with guidance from the Development Team. Do not try to avoid bugs. Show them so the Stakeholders are aware of them. Use this as an opportunity to find the “faults” rather than just show the progress. By finding the faults, you know where your improvement needs to focus.

This is where the term “Showcase” comes from. It becomes a “Show and Tell”. A Showcase does not help the product get better which is the goal of the Sprint Review.

The Product Owner discusses the Product Backlog as it stands. He or She projects likely target and delivery dates based on progress to date (if needed).

This is to give transparency to the Stakeholders so they have a rough guess as to when the product will be finished or the feature they are interested in is finished.
Based on the work to date, completion of the Backlog can be determined based on current progress. Such as Burn down charts.
If for example progress is slow and delivery dates could be missed, the Stakeholders can discuss dropping features that are no longer required.
Ultimately though, the final decision rests with the Product Owner.

Target and Delivery dates should not be arbitrary. For example set a date to get the team to work faster. This adds stress to the overall process. Leading to teams working late into the night to meet a false deadline only to find out that is made no difference. This becomes very demoralizing for the team. It also shows disrespect for the developers as there is insinuation that the developers are not working to their best capability.

The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.

The key here is collaboration. Everyone gets a voice. Everyone has input.

Review of how the Market Place or Potential use of the Product might have changed, what is the most valuable thing to do next; and

Things can changes, the Stakeholders, Product Owner may reject what has been done. This is always a possibility. Not only for new work, but for work already done.

Review of the timeline, budget, potential capabilities, and market place for the next anticipated release of functionality or capability of the product.

This may include canning the project/work. If enough value has been reached, then work can stop.
This needs to be taken into account.

The result of the Sprint Review is a revised Product Backlog that defines the probably Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

This is a deliverable of the Sprint Review. It is up to the Product Owner now to determine to include the new items and their subsequent priority. This is just one aspect of the Product Backlog. These items may need further grooming by the Product Owner and the Development Team.
Everything is up for re-ordering, removal or addition. Nothing is fixed.
The Plan Potentially changes yet again!

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvement to be enacted during the next Sprint.

This is part of the final portion of the Plan->Do->Check/Study->Act cycle. It is a formal time when the team reviews how they have worked. The output should be a plan (or experiment) on a way to improve the current situation. It doesn’t have to be a big change, but there should be a change. The requirement for chance is to prevent stagnation.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprint. For shorter Sprints, the event is usually shorter.

Again time boxed to a maximum time.
Two week sprints, usually 1 ½ hours is allocated.

The Scrum Master ensures the event takes place and that attendants understand its purpose.

This is an interesting statement. It means that the Retrospective is for the Team, by the Team. It is not the Scrum Masters role to “Run” the Retrospective. They merely facilitate the Retrospective.

The Scrum Master ensures that the meeting is positive and productive.

Retros are just a waste of time.

If the feeling by the Team as a whole is that the Retrospective is a waste of time – do something about it! Discuss why it is a waste of time and look at ways to improve them.

One common mistake is to skip the Retrospective when it is a “waste” of time. This only “hides” the problem, it does not address the problem. Scrum’s purpose is to expose problems, in this case a meeting for improvement that doesn’t do anything. It is up to the Team to actively make the meeting useful. Scrum can’t fix passivity.

The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum Process.

Interesting note, there is no mention of the 3 questions in a retrospective anymore.

What went well during the Sprint?
What didn’t go well during the Sprint?
What needs improving?

While these questions are answered – they are not directly asked. The answers must be encouraged from the team.

What if people have nothing to say? They shouldn’t be made to talk.

That is all well and good, but I cannot tell the difference between not having something to say and not saying anything because…

You are afraid to
You are intimidated not to say something because the environment isn’t safe.
You think no one cares about your view.
You’re pissed off.
etc

The only way to be sure is encouragement of participation to bring the issues out in the open and make sure it is safe to do so.

The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process and tools.

This isn’t a time to go through the work output itself, but how the work was done.

How the team worked together, if well
Any experiments on how to work. i.e. making work visible, limiting Work In Progress (WIP), Working from home, etc.

The Japanese word Hansei comes to mind. Acknowledge ones mistakes and pledge improvement.

Identify and order the major items that went well and potential improvements.

What did we do well that we don’t want to forget?
What did do well that we can exploit to improve other aspects of the process?

Create a plan for implementing improvements to the way the Scrum Team does its work.

This I think is the most missed out thing with Retrospectives. Planning the improvement. If you do not plan to improve, the Retrospective becomes useless. It is all well and good pointing out areas that need improvement, but not doing the improvement guarantees failure.

If you do plan, plan it as an experiment. Have a hypothesis, determine the expected result and actually see if the result is reached. Determine a timeline to review. It could be the next day, week, sprint, month, but you need that review.

The Scrum Master encourages the Scrum Team to improve, within the Scrum Process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.

This gives you permission to make things better. Challenge the status quo and have fun doing it.

This gives permission for those in “death” Scrum to challenge their situation. I know I don’t find “Death Marches” fun. Maybe you do? but I don’t.

Change things up to make them enjoyable. If its not, you are doing Scrum wrong.

During the Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with Product or Organisation standards.

This is self inspection of the work process, the Sprint Review covers the improvement of the work output.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that they will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaption to the inspection of the Scrum Team itself.

Self Improvement

Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on the Inspection and Adaptation.

I don’t like the statement “Improvements may be implemented at any time”. This can insinuate that they may be put off due to “other” work and thus never be implemented. I think an additional statement that improvements should be “tested” as soon as possible. I realize that improvements may need to be put off , but adding “as soon as possible” means they should not sit on the Backlog forever. Also, by specifying “tested” acknowledges the fact that an improvement may not actually make an improvement. Thus testing, even a small test will help verify this before implementing a large unweildy improvement.

That was a long section. We’re on the home stretch.

I actually only got this far when I was studying for my PSM certification. I had gone through the Scrum guide so often, and I decided to wing the test and try. Low and behold I passed.
This doesn’t mean I’ll stop here for this decomposition. I still think the exercise is worth while doing, so over the next few weeks I’ll be doing part 4. At the end of part 4, I’ll also include the written version as an attachment for anyone interested. Yes, I wrote the Scrum guide out by hand!

Let me know in the comments if you have found this useful.

Blog

Scrum Guide – Decomposition Part 2

June 27, 2018 admin Leave a comment

This is the second part of the Scrum Deconstruction. You can find part 1 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.

Here I share in the hope that someone finds it useful.

Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.

Sections in Black will be me rephrasing or my interpretations of the paragraph. This I would like to think of as the positive aspects of Scrum.

Side Notes are in green.

Now, lets get on with the deconstruction.

The Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and the Scrum Master. Scrum Teams are self-organizing and cross-functions. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

By letting teams self-organize rather than being told what to do, they are given ownership and authority over their workload. Studies have shown that when you have a high sense of control over your work, you are less likely to suffer from stress and actually be more happy. You also work harder. You have more control over your destiny.

Self-Organizing! Teams would not do anything. People are lazy if they are not told what to do. The work will never get done.

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

In the Enterprise, it would be difficult (but not impossible) to have a team with all competencies to do all the work simply because teams are siloed into specific competencies. For example, DBA’s, Middleware, specific back end systems like SAP and so forth. The enterprise unwillingness to break apart these silos may hinder them from fully getting the benefits of Scrum.

By having the team members that are cross-functional, bot not necessarily proficient in all competencies, you can avoid delays when someone for example is sick or on leave. Someone can continue the work. The team can also share the workload. No single person is carrying the team because they are the only person who knows that competency.

The term “Jack of all trades – master of none” comes to mind. Good luck finding people who know everything.

It is the team as a whole who becomes the masters. Not individuals.

The Scrum Team has proven itself to be increasingly effective for all the earlier stated users, and any complex work.

A team of 3-9 people working together towards a common goal.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

You are able to seek feedback sooner. Make corrections earlier and thus reduce the chance of going too far building the wrong thing. Thus reducing wasted effort saving time and money.

Just get the damn specs right in the first place. Get it locked down and signed in blood. Then it becomes the customers fault if they got it wrong in the first place.

The Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is responsible for making sure that the development team optimizes its work to produce value. This can be done by…

Prioritizing work based on value.
Communicating the backlog to the development team so they understand what needs to be developed.
I’m also getting ahead of myself.

Yes – if you used Scrum to build a house, you would build the roof first as that gives the most value, then the walls, then the floor.
Side note: Yes – someone has used that argument with me before.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and;
Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner needs to make sure the Development Team has enough information to hit the ground running when they start on an item. This may be before the sprint (preferable) or during – the it is the Product Owners responsibility.

So what does the Scrum Master do? Seems like the Product Owner does all the work!

The Product Owner may do the above work, or have the Development Team do it, However, the Product Owner remains accountable.

The Product Owner is one person, not a committee.

This is so that one person’s vision is fulfilled. Not a bunch of random requirements from different people. :- RoboCop II comes to mind where his directives were done by committee. RoboCop pretty much couldn’t do anything without violating something.

The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

What happens if you get a Product Owner who ignores the committee – or the users?

This is a risk – in which case it is for the committee and Product Owner to work out.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

This is actually to minimize the chopping and changing of tasks for example when a developer is asked by 5 different managers to get their little piece of work done.

But how does anything get done? Manager A needs his thing, Manager B needs his. I have mine. It all needs to be done and it all needs to be done now!

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.

Basically treat each Sprint as a mini project. You do not have projects where you do only documentation or a project that only does testing. You do everything and at the end of that project, you release. At the end of your sprint – you need to be in a position to release – if needed! This then puts the decision to release on the Product Owner (The Business) and not hampered by the development team not being ready.

But we are not in a position to release at the end of the Sprint!
There is too much work to be done!

You have taken on too much work for the Sprint.

Slow down, sometimes you need to slow down to speed up.
You need to break down the work more.
You need to make sure the Increment provides some (Doesn’t have to be a great deal) value.

Development Teams are structured and empowered by the organisation to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

The Team chooses the work they do and how they do it. By “empowered”, the Development Team has the authority to accept or reject work as they see fit. If an item on the backlog does not have enough information for the development team to work on, and its not coming any time soon – or the Development Team is uncomfortable doing the work, then they have the authority to say ‘No’

The team also works out the best way it can get the work done.

But what if the Development Team gets it wrong? They completely screw up?
They need to be ‘told’ what to do and how to do it so it doesn’t happen.

Yes the team can screw up. Although the team cannot be ‘told’ what to do, they can be guided.
If they screw up – then the team learn what did and didn’t work. Instead of wasting months with traditional development – only a sprint (up to 1 month) is wasted.
This is a chance for all the Development Team to learn.

Development Teams have the following characteristics:

They are self organizing, No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into increments of potentially releasable functionality;
Development Teams are cross-functional, with all the skills as a team necessary to create a product increment;
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- No Senior Developers
- No Architects
- No Testers
- No DBAs
- etc

Who leads the team if there is no senior?

It is an egalitarian structure. Everyone has a say, everyone is equal.

That would be anarchy!

This is why the team is made up of “Professionals” and not animals.

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

All for one and one for all. Everyone needs to look out for one another.

Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains.

If you have 1 or 2 developers, the interaction between developers is already there. Scrum could actually decrease that interaction because of the formal times. This causes the productivity gains to not be as much as for larger teams.

So you see – Scrum doesn’t work – albeit for smaller teams.

Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment.

Too few people may not have all the required skills, but not always.

Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for the empirical process to be useful. The Product Owner and Scrum Master riles are not included in the count unless they are also executing the work of the Sprint Backlog.

The more people you have, the more communication channels there are. We as humans can only support so much at any one time.

The equation is:
communication channels = n(n-1)/2 where n is the number of people.

So for 5 people, n = 5 we get
5(5 -1)/2 = 10 channels.

for 9 people, n = 9 we get
9(9 – 1)/2 = 36 channels

for 10 people, n = 10 we get
10(10-1)/2 = 45 channels

At this point (and most likely lower) our brains cannot keep up with the number of people at once.

See – Scrum doesn’t work with large teams either. Only a specific set. Business doesn’t work that way. It might work well within a startup for a web application but not Enterprise.

Enterprise may be looking at it the wrong way which is why they are having troubles keeping up with Smaller Agile companies/teams and why they are scrambling to keep up.

The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules and values.

The Scrum Master is a servant-leader for the Scrum Team, The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The Scrum Master:

Helps the team Understand Scrum
Helps them stay within the Scrum Framework
Without a Scrum Master practices may slip back to what is comfortable, which is the process already known. For example,
- Waterfall
- Standard Command and Control Management
- or worse cowboy development in the name of Agile.

The Scrum Master does this by not being in charge – but by guiding the team.
A servant leader is on that coaches to get you to your best. They are not there to tell you what to do, but to help you make the right decision.

Who is in charge then? If the Scrum Master does not direct, then developers will do nothing.
Its the inmates running the asylum, and the Scrum Master does nothing.

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways including:

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
Finding techniques for effective Product Backlog management;
- Such as User Story Mapping
- Impact Mapping etc
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- The more clear the team is on what needs to be built, the less time is wasted asking silly questions or getting stuck or building the wrong thing.
Understanding product planning in an empirical environment;
- Don’t plan everything up front. Do a bit, evaluate and plan the next move.
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
- Draw out from the Product Owner what he could use now, not at the end of the project.
Understanding and practicing agility, and;
Facilitating Scrum events as requested or needed.
- Help the Product Owner become more available to the team.

Scrum Master Service to the Development Team

The Scrum Master servers the Development Team in several ways, including;

Coaching the Development Team in self-organization and cross-functionality;
- Guide the team to make good decisions without making the decisions for them.
  This is easier said than done as the team will make mistakes. The trick is to let the team make the mistake, have them recognize the mistake and let them correct the mistake.
  Also have team members work in areas that are not their specialty. This can help the team become more cross-functional.
Helping the Development Team to create high-value products;
- Don’t ignore quality
- Reduce waste
- Get the team better at their skills.
Removing impediments to the Development Team’s progress;
- Anything that stops the team from completing a task. Could be related to People, Process or Technology. Need to identify impediments early to reduce their effect.
Facilitating Scrum events as requested or needed; and,
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
- Try to prevent the team from reverting back to their old ways. Especially during the difficult transition period.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including;

Leading and coaching the organization in its Scrum adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact Scrum and empirical product development;
Causing change that increases the productivity of the Scrum Team; and,
- Find ways and experiments to help increase productivity. Research different methods.
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
- Collaborate together
- Share ideas
- Not everyone wants to do Scrum. Don’t force it down my throat!
- Hence the Scrum Master needs negotiation skills.
- Not everyone can work under Scrum, this needs to be taken into account.

This is it for Part 2.

Blog

Scrum Guide – Decomposition Part 1

June 19, 2018 admin Leave a comment

When I was studying to do my PSM I Certification, I decided to deconstruct the Scrum Guide. I would write out paragraphs by hand, then write down what I understood about them. Over the next few posts, baring anything more interesting coming up, I would like to share my thoughts on the Scrum Guide.

Sections in Blue will be taken from the Scrum Guide. I’m not going to do a cut and paste, but re-type out what is present. Therefore there may be mistakes.

Sections in Black will be me rephrasing or my interpretations of the Paragraph. This I would like to think of as the positive aspects of Scrum.

Sections in Red will be the negative aspects that I see, or have been told, read or anything else negative. Sometimes these will sound silly as it I find it difficult to find negative aspects, this is where I ask for help. If you have more constructive negative feedback about a paragraph, please let me know in the comments.

Now, lets get on with the deconstruction.

Purpose Of The Scrum Guide

Scrum is a framework for developing, delivering and sustaining complex products. This guide contains the definition of Scrum. This definition consists of Scrum’s riles, events, artifacts and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Definition Of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a framework, not a methodology. A Framework implies that it is something you build upon.

A framework implies it is not complete.

It addresses complex and adaptive problems because it uses an empirical process to analyse the work to be done.
By regularly ‘checking’ to see of the right thing is being done.

Productively – By continuously looking for ways to do things better (Retrospective).

Creatively – By using everyone’s input to solve problems. Problems are raised through the daily scrum and retrospective.

Highest possible Value though defining quality through the definition of done. Never compromising on quality.

Open to abuse. People who use scrum as a method to get things done quickly leave out quality altogether.

Scrum is:

Lightweight
Simple to understand
Difficult to master

Because it is so simple, it is easily communicated.

Because it is simple, things can be skipped and misinterpreted opening up avenues of abuse. Its simplicity can give a false sense of mastery, especially when not fully understood.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

It is not new. It has been around for over 20 years!

Ages does not guarantee feasibility – but its a good argument for it.

Scrum is not a process, technique or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

A framework is something to build upon. A base.

The mere fact it is a framework invites chopping and changing to suit your needs – it implies things can be “Taken out”.

Scrum makes clear and relative efficacy of your product management and work techniques so that you can continuously improve the product, the team and the working environment.

Efficacy – The ability to get the job done under ideal conditions.
By making things clear, you can change it if things are bad.

Under ideal conditions, it doesn’t work in the real world (So I have been told – and I did say some of the negative aspects would be silly) Conditions are never ideal.

Because you have visibility – nothing is stopping you from changing things to make them ideal. Hence improvement!

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrums success and usage.

Everything in Scrum serves a purpose – it is not put there just for the hell of it.
But we don’t need all those things. It takes up too much time! We can live without it all.

The rules of Scrum bind together the roles, events and artifacts governing the relationship and interaction between them. The rules of Scrum are described throughout the body of this document.

The rules of Scrum dictate how the roles, events, artifacts – overall the components how they interact with one another.

Rules? Who needs rules? Can’t you just get the ‘gist’ of it? Also, the Agile manifesto mentions Individuals and Interactions over Processes and Tools. If Scrum has rules, it must be a process. If it is a process, then it can’t be agile!

Specific tactics for using the Scrum framework vary and are described elsewhere.

Since Scrum is a framework to build upon, how to build upon it is covered outside this document. It also means that Scrum can be used outside of Software Development.

Since how to follow Scrum is not covered for every situation and you need to do more reading – no wonder a majority of Scrum.Agile implementations and transformations fail.

Uses Of Scrum

Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide to:

Research and identify viable markets, technologies and product capabilities;
Develop products and enhancements;
Release products and enhancements, as frequently as many times per day;
Develop and sustain cloud (online, secure, on-demand) and other operations environments for product use; and,
Sustain and renew products.

Scrum/Agile has been used both inside and outside of Software Development. It has been used to train police forces (Ghana Police Force), legal teams (Lost Planet), the banking sector (ANZ), Education and many more.

Scrum has been used to develop software, hardware embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing managing the operation of organisations and almost everything we use in our daily lives, as individuals and societies.

As technology, market and environment complexities and their interaction have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.

Scrum proved especially effective in interactive and incremental knowledge transfer. Scrum is no widely used for products, services and the management of the parent organisation.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many and network teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and inter operate though sophisticated development architectures and target release environments.

I don’t need to say more!

When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types defined above.

This is to detract from the roots of Scrum in Software Development where the term developer and development come from. The term is widened to incorporate anyone who works in complex work.

Scrum Theory

Scrum is founded on empirical processes control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Make an assumption
Test that assumption
Evaluate that assumption
Determine what to do with the assumption
Repeat

Use a feedback loop to determine decisions. Base those decisions on evidence gathered, not speculation.

But I just want to know the one true way that will solve all my problems! Scrum does not give me that. It does not explain why it is better (or the best) process!

Three pillars uphold every implementation of empirical process control: transparency, inspection and adaptation.

Transparency

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

Stakeholders/Developers, basically everyone involved must have a common language and point of reference to understand what is being seen – the process itself and all aspects of the implementation.

For example

A common language referring to the process must be shared by all participants; and,
Those performing the work and those inspecting the resulting increment must share a common definition of “Done”

You don;’t need a common language, just ‘tell’ the developers what to do. They are smart. They will figure it out.

Done is ‘done’ when I say it is ‘done’! So what if it hasn’t been tested. Then it will be ‘done-done’!

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

In other words, keep looking for problems (undesirable variances). Don’t let the looking (and subsequent fixing) of the problems get in the way of doing the work. Use the work to find and fix the variances (variances taken from W. Edwards Deming?)
The best inspectors are the ones who both do the work, but also know what variances to look out for. Problems can also be defects!

But I don’t have any variances/problems!

Not having variances/problems is a problem in itself, LOOK HARDER!

Adaptation

If an inspector determines that one of more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Here a feedback look is established based on quality. If there is a deviation in “quality”, be it software quality or process quality then an “adjustment” is made to bring it back in line. Also, the adjustment must be made as soon as possible, not only in terms of time (which dictates the cycle time of the feedback loop) but also in terms of where the variance is happening. By this I mean fix the variance at the source, not after the inspection. i.e. after the fact.

We have tests, we’ll raise a ticket so the “variances” are fixed at some point in the near or distant future (If at all).

Scrum prescribes four format events for inspection and adaptation, as described in the Scrum Events section of this document:

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

Meetings, meetings and more meetings!

Scrum Values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspections and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events and artifacts.

The Scrum House?

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right hing and work on tough problems.

The right thing is not to use Scrum!

Everyone focuses on the work of the sprint and the goals of the Scrum Team.

Do not focus too much on just the work, but also improving the work. Focus on only the work leads you into a rut where you don’t get better, you just keep doing the same thing because it gets the work done. In this case, especially when things are most busiest, it takes courage to stop doing the work and focus on improving the work.

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Here these values and pillars are used to help build trust in the team. Trust is when you trust the Scrum Master to have your best interests. Trust that the Product Owner will not waste your time on meaningless work. Trust that your fellow development team members have your back.

Without trust (5 Dysfunctions of a Team), you know your fellow team members will not have your back. Put you down on your weaknesses, discourage ideas that are different. This leads to lack of conflict. The ability to discuss the non-con-formative. In other words, absence of courage and openness. Since people no longer feel happy, they have no say, they switch off, they are no longer committed. They no longer have authority over how to do things. They are just told what to do, thus lack the sense of responsibility. Thus have no respect for their fellow team members.
Thus there is no focus on the goals. This is where Scrum fails.

That is it for the first part. Stay tuned for more.

This also marks the 100th post on this blog. This blog is several years in the making. from the first post in Mark 2015 where I started the blog after running a blog freely hosted on WordPress, and then the one before that when I worked at Sun Micro Systems and used the companies blogging framework.
If you haven’t already, I suggest looking at some of my past posts and see how my views on Agile have changed over the years.

Update : Part 2 of the Scrum Guide Decomposition can be found here.

Blog

Just Don’t Do Agile

June 13, 2018 admin Leave a comment

This is a very in your face title especially for a blog that focuses on Agile. Have I lost my mind or come to my senses? Probably neither (I list my mind a long time ago), but hear me out.
We should not be striving to do agile, we should be striving to be agile. For me, agility means being able to accept change without consequences. Consequences mean disruptions in the form of re-allocating work. Putting things aside. Stopping what you are in the middle of doing and doing something else. Can we do that? Probably not, but that isn’t the point. It is the idealistic goal.
When you “do” agile, the usual reason is that you want the benefits of agile. Faster turnaround, less bugs, higher quality. The thing is, just “doing” agile won’t give you that. You can do all the stand ups you want. Have sprints, retrospective and have the board. It generally is meaningless. Sure, you may make some progress but you are not agile. You are only going through the motions. If you really think about it, doing agile may actually make the same amount of work take longer than waterfall. Yes, I did say longer. The reason is that with agile there tends to be a lot of rework. You build a little something. Get feedback, if that feedback is negative, then you may have to do that work again. The thing is that you are only doing a little bit more work. You are also building something that the customer wants or needs. With waterfall, you get feedback towards the end. If that feedback is negative, usually what happens is that it is now too late to change anything. So, the work is forced onto the customer. They have no choice unless they are willing to delay. So they live with it. Not a happy customer, but they have had this for so long that they are use to it.

So, don’t have the goal of doing agile, Have the goal of being agile.

So how does this look?

Let’s start off with a trip to Lala land. Where everything works as intended.

In every project in Lala land, they have a scrum board. Just like what we have, but in Lala land, work flows smoothly from one end to the other. New requirements come in, they flow from one stage to the other synchronously. When the developer finishes development,the tester has just finished testing the last lot of work and thus pulls the work from the developer and tests. The same with UAT and finally the move to production is done immediately after UAT finishes and only takes minutes. I hear you say, let’s be pragmatic. This is not the time to be pragmatic. That will come later. This is the time for dreams and idealization.

So, what are the benefits of working in Lala land?

Work flows freely without delay. There is no backlog as work is done as soon as it arrive. There is no need for rearranging work as it gets worked on as soon as it is commissioned. In other words, this system is agile. Change can happen on a whim with no repercussions. Sounds like a fantasy. It is.

Now we bring in reality. There are delays with work. It starts to build up or has already built up. Deadlines loom, and we have organized chaos. This is the current situation and you have probably been doing agile and see this mess.

So the question is, do you want to live in this situation, or do you want to live in Lala land? I’m guessing Lala land. So, how do you get to Lala land? First thing, do t accept the current situation. Second thing, do something that moves your situation a little closer towards Lala lands ideal. This is where doing agile comes in.

The way I see it Agile processes do one of 3 things.

Highlight problems
Solve Problems
Highlight and solve problems

1 being the predominant focus. In other words, Agile processes help you identify problems towards being Nimble. It is the permanent solution to those problems, not workarounds that help you attain agility.

For example. In Lala land, they accept change without any consequences, but how can you accept change without any consequences, if you are working on something. You have to stop what you are doing, then do rework to accommodate the change. Here is our first problem. So instead of saying “It can’t be done”, think “How can we do this?”.

One method may be to break down the work into smaller chunks so that when a change comes in, a smaller chunk of work is disrupted instead of a larger chunk.

So what needs to be put in place to break down work into smaller chunks? Here is our next problem. Well, we need to spend some time breaking that work down. When should we do that? And so forth. You may then get a whole list of things that need to be done to attain the goal of accepting change with no consequence. Some will be easy to implement, some will be hard. Don’t worry about that, Just pick the first thing on the list, determine what you expect to happen once it is implemented, then implement it.

Once implemented, evaluate. Did it achieve what you expected? Yes, yay! Does the next thing on the list still make sense? Yes, implement. If either of these questions return No, then learn why then rethink your plan. This will happen frequently. Circumstances change, just re-evaluate and try again. It’s part of the journey to being agile. Did I mention that you need to do this while still doing your normal work? Well, you do. So you can’t spend weeks or months doing improvement while ignoring your normal work. The only way you can do this is to continuously do a little bit every day. Every bit counts. Continuously improve just a little every day towards that goal of being agile. Now that you start doing this, the agile processes such as scrum, Kanban, Lean Software etc will add structure to what you are doing towards being agile. This is the doing side. These will help you find the problems towards being agile, solve them and move on.

What people tend to do when the do agile without being agile is the goal is ignore the problems, push things faster and then wonder why it all falls apart. Try not to fall into this trap. If you do, you or those under you may end up hating agile because it is a really really bad experience.

Creating The Servlet

Adding the Python Libraries

Set the Default Application

The Basic Board Layout

The Basic Card Layout

Analysis

Product Backlog

The Cone of Uncertainty

Monitoring Progress Towards Goals

Sprint Backlog

Monitoring Sprint Progress

Increment

Artifact Transparency

Definition of Done

End Note

Scrum Events

The Sprint

Cancelling A Sprint

Sprint Planning

Topic One: What can be done this Sprint?

Topic Two: How will the Chosen Work get Done?

Sprint Goal

Daily Scrum

Sprint Review

Sprint Retrospective

The Scrum Team

The Product Owner

The Development Team

Development Team Size

The Scrum Master

Scrum Master Service to the Product Owner

Scrum Master Service to the Development Team

Scrum Master Service to the Organization

Purpose Of The Scrum Guide

Definition Of Scrum

Uses Of Scrum

Scrum Theory

Transparency

Inspection

Adaptation

Scrum Values

Thoughts, Tutorials and Learnings specifically with regards to Agile, DevOps and SOA/EAI