Thoughts for improving your business

What is agile? Get in touch

Sarajevo Special Scrum.org Product Owner Training

sarajevo_sprawling_along_the_miljacka_river-sarajevo
Studies* show that certain memories help us learn and remember more effectively. Combine a course with a team building exercise, an appraised movie, and you have something amazing – a training with lasting impact.
This is exactly what we wanted to achieve with the first Bosnia Agile organised Scrum.org Product Owner training.
The PSPO (link) training was build around two events, the Sarajevo Film Festival  and a rafting team building exercise. It does not come as a surprise that this event was sold out 6 weeks ahead.
IMG_7772 20140823_125104
Between watching a great movie ‘The Railway Man‘ and rafting in this beautiful region, the students where also learning everything important about Scrum, value, lean and agile product ownership. Since I was the trainer it might sound pretentious from me to say how awesome this training was, but in all modesty, it truly was. It was an outstanding and new experience not just for myself. I made many friends and shared many great moments with my fellow students. I am sure that Sarajevo played a big part in this. Sarajevo, the capital of Bosnia-Herzegovina, is a very dynamic and friendly city surrounded by beautiful nature and with good reason was the host for the ’84 Winter Olympics. I for myself cannot wait to go there again.
25 happy Product Owners and a happy trainer cannot be wrong. We have been so pleased that the organisers and I decided to repeat this setup once again next year.
If you live somewhere in the EU you should consider combining education with worthwhile memories. More training content will stick and even better, you will have more fun learning. Consider this: even with budgeting in the costs of transportation and accommodation, it is probably still cheaper than your near-by training provider.
See you next year at the 21st Sarajevo Film Festival …
20140823_123552 20140822_115801 20140822_115508
*)

The Antibiotics of Software Engineering – Agile Testing


Surgery is not a recent invention, it dates back millennia. 

Notable Milestones in Surgical History (http://surgery.about.com/od/surgeryinthemedia/a/HistoryOfSurgeryTimeline.htm)

6,500 B.C.E. – Skulls found in France show signs of a rudimentary surgery called trepanation, which involves drilling a hole in the skull.
1540 C.E. – English barbers and surgeons unite to form The United Barber-Surgeons Company. These barber-surgeons performed tooth extractions and blood letting. Physicians were considered an entirely different profession, treating illness with medications.
1818 – First transfusion of human blood.
1843 – First hysterectomy performed, in England.
1843 – First use of ether.
1867 – British surgeon Joseph Lister publishes Antiseptic Principle in the Practice of Surgery, extolling the virtues of cleanliness in surgery. The mortality rate for surgical patients immediately falls.
1885 – First successful appendectomy performed, in Iowa.
1890s – Widespread use of chemical agents to minimize germs. Carbolic acid was put on incisions to minimize germs and decrease infection rates.
1896 – First successful heart surgery performed, in Germany. Surgeons repaired a stab wound in the muscle of the right ventricle.
1905 – First successful cornea transplant.
1917 – First documented plastic surgery performed, on a burned English sailor.
1928 – Antibiotics discovered.

Even if the procedure was successful, often the patient suffered and usually died of subsequent infections. 
Also, not to ignore is the discovery of Ingnaz Semmelweis, a physician at a Vienna hospital. While working at a Vienna hospital in 1847 he discovered that far more women died after childbirth by the so called childbed fever in the medical ward then in the midwifes ward. Semmelweis postulated the presence and spreading of germs causing the illness by doctors. Even though, after applying a chlorine and lemon based hand-wash solution the death rate could be reduced from ~35% to 1%, he was being labeled a heretic by the doctors. Ignaz Semmelweis was ignored until Louis Pasteur confirmed the germ theory.

Now, after it was accepted that germs caused infections and that hygiene was mandatory for good outcomes it became also obvious that there was a need to have a treatment once an infection set in. As listed above, on September 3rd  in 1928 Alexendar Flemming discovered the antibiotic effect of Penecillin and transformed medicine as we know it. Nowadays, antibiotics are used to treat all kinds of infections and antibiotics are prescribed in a preventive manner for many medical procedures. 

In software development we are able to develop rather fast and make significant changes to existing systems quickly. However, after these procedures the system often falls sick, suffering from bugs, side-effects and other ailments. I like to consider these as infections. Those infections even arise after well planned and executed engineering efforts.
The fundamental question is, how can we cope with them or even better avoid them – what is the the antibiotic equivalent in programming?
For me, the answer is: Agile Testing

Agile Testing is the process to validate that new functionality performs correctly and more importantly to verify that the existing behavior has not changed – that no infection has set in.

1. We have proof that the current system is healthy before the procedure starts
2. We are able to monitor the systems health during the procedure
3. We can intervene the moment side effects set in
4. We have proof that the procedure was successful 

A well done Agile Testing strategy is the equivalent to clean medical equipment and antibiotics. 

Agile A3 Sprint Report

I really enjoy working with A3 Reports. They have the habit of making you to distill out the crucial information, to really drill down.
There are different kinds of A3 reports. The book ‘Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System’ describes three different report types. Problem-, Proposal-, and Status Report. The Problem Solving is the one I use most often.

So what is an A3 report. A3 Reports are size limited and have to fit on an A3 size of paper (for US folks, it is 11.69 × 16.54 inches). The size limitation requires to only present important informations. Furthermore, the use of charts, graphics and other none textual descriptions is highly encouraged. The less words the better. Since the Problem A3 Report describes the current and the target situation they serve as excellent PDCA (plan do check act) tools.

In my profession as Scrum coach, I grew tired of all the different and bureaucratic status reports. Usually the decision makers require lots of text and a traffic light. The text does not get read and all decisions are based on a single color. So, my idea was to create an A3 Report which is hardly text and more differentiated then only one color. Providing a quick and easy way for more information width. 

This is how it looks like:
REPORT_1_SprintA3Report
Top Left – Sprint Burndown
Current Sprint burndown. Blue remaining work in hours, Green remaining Story Points

Top Right – Release Burndown (Burnup in this case)
Up to date, including last Sprint, release burnup

Bottom Left – Risk list 
Up to date, risk list a la Frederic Brooks. New risks are continuously discovered and either handled by outside help (i.e. by the Scrum Master) or they get put into the Product Backlog and mitigated when the Product Owner puts them into a Sprint. The risk list is dynamic and subject to change from Sprint to Sprint. (*) Mitigated risks are kept on the list.

Bottom Right – Open Bugs
Up to date number of open bugs. If I can have my way on a project, the 10-Finger-Rule applies. The moment you run out of fingers to count bugs, you need to fix bugs first. This guarantees clean, maintainable and sustainable code. If a bug is rather tricky to fix, it can be put into the Product Backlog analog to a risk. Again, the Product Owner then schedules the fix, if she sees it to be appropriate. Also, this avoids the growing number of bug triage meetings towards the end of an project (**). If you work on an legacy project with X bugs, the rule changes to X+10. Done right, X will decrease over time and product quality will go up.



(*) On many projects the institutionalized company process requires a risk list. So, at the early beginning of the project a risk list is compiled, checked off on the check list and then put into a drawer. No transparency and accountability.

(**) On many projects you you have severity levels from P1 to P4. With P1 being worst and P4 minor. Usually, you have a company mandate, that no software can be shipped with open P1 and P2 bugs. Guess what … in the growing number of meetings after each bug fixing cycle, panic tends to creep up. The human reaction is to ‘mis’-label P2 as P3. Problem fixed, process followed.

An Agile Transition done Right



A little over a year, I kicked off an agile change program at a leading swiss devices company. Two weeks ago, I had a chance to visit them during an open house on their new premisses.

This company was fully committed to walk the talk, they decided to do what needed doing.


In August 2010, we started of with a five day PSD (Java) Scrum.org training. I trained 12 very strong developers of various expericene levels. This training was intended to ascertain whether they really want to work in an agile manner. Brave move from management, but to no surprise the developers fell in love with Agile and Scrum and were hooked on day three of the five day training. This training is excellent!
After the developers gave their thumbs up, it took about a month to set everything in motion. This is is a mid size company with over 300 employees at their head quarters. Once we got the ball rolling the company was ready. They had torn down walls to create right sized team rooms, organized great Story Boards or shall I say walls. Again, they were serious. In the first two weeks, apart from coaching the teams, I trained ten people as Scrum Master (PSM) and ten more as Product Owner (PSPO). We didn’t really know who is going to fulfill which role, we just knew that the future person would be coming from those groups. Also, the intention was to really create an agile culture and what could be better then to reach out and train and convince as many people as possible. After that I gave about ten introductions to Scrum, each lasting about two hours; the target audience was marketing, sales, support and other departments on the projects periphery.
For the frist two sprints — 2 weeks in duration — I was coaching a 100%. Essentially being a Scrum Master. After two Sprints I was only around at the beginning and at the end of the Sprint. During my absence the teams had the chance to walk on their own without training wheels, getting first-hand experience into when they started to struggle. After 5 Sprints the teams decided on their own who should replace me as the Scrum Master. In the remaing four Sprints, I worked closely together with my replacements. My presence became less and less. At the end it was about 20% of the time. By the end of last year, they didn’t need me anymore and I moved on.
This whole engagment lasted about four month in calendar time and about two month of coaching from my side.

Now, during the open hours, I had the chance to meetup with a couple of guys from the old teams and we chatted a little. It was a great to see, that all of them really had drunken the agile CoolAid. They did not roll back one inch – instead they kept on pushing hard. Now, there are three teams and more coming soon.
For me and my company effective agile. this coaching approach has become my favorite modus operandi for change engagements.


By the way, the last two releases were two and six weeks early! It humbles me to know, that I was the initation.

PSD (Java) First Run

Most Scrum implementations fail or have limited success for one reason. The team is not able to really deliver a potential shippable product increment according to the definition of done. This causes all kinds of problems down the road. One of the main manifestations is that the the sprint cadence goes over board. By loosing this, you loose one of the main points of transparency.

This problem was described by Martin Fowler in his Flaccid Scrum article and by Ken Schwaber in an interview. Ken, then left the ScrumAlliance to found Scrum.org so that he can address exactly this problem. Professional Scrum Developer (PSD) is the result. There are two tracks, one for .Net in C# and one for Java. I co-developed the Java course which is build 100% on open source tools. It is an intense five day class in which the developers are exposed to a real live scenario, in which they have to deliver working software according to the definition of done in 4 mini sprints. It includes all aspects of Scrum like, sprint planning meeting, daily scrum, review and retrospective. The five days are very intense. My goal is to provide each participants with the feeling and experience what real Scrum feels like. Once, you have experienced this, you know exactly what you should aim for. You want that feeling again!

The first Java PSD was held in Zürich, Switzerland from June 4th-10th. Ken Schwaber attended the first day and really liked what he saw. The overall feed-back was very positive and I am happy to know that there a eight more ‘real’ agile developers in the field. I believe that the earlier you get a change to work with programmers the more they get out of it. Therefore, I am wondering if it would be possible to even integrate that training into the curriculum of computer science studies.

If this sounds interesting, then go to Scrum.org and check out the available training side. Also, I will be giving a Scrum in Depth (SID) class in Bern, Switzerland on June 5th-6th. IMG_6173 IMG_6215 IMG_6195

Productive Meetings


Don’t know what your experience is like, but for me it is the following. Meetings are much more productive when someone is standing at a white board and writes down ideas, risks, problems and what have you. I am sure every single human being who has attended enough meetings has observed the default pattern — or anti pattern — in meetings. Everyone has their point of view and does all necessary arguing to protect their idea. They fight each other instead of pulling together towards a common goal. Often after a long and useless meeting it is commonly decided (the only agreement) that another meeting is needed.
One way to counter this behavioral pattern is to mail out an agenda with all the topics and asking the participants to prepare. This might help but most often it does not. I even doubt that every recipient of the mail does read it entirely. It usually drowns in the sea of more important emails.
Now, imagine you are in a pissing contest meeting and someone gets up and starts to write the different points clearly visible down. In a heart beat the whole meeting has structure, everyone turns their head towards the board. Not the loudest voice is heard but all ideas. Often, after some time the whole group is working together towards a — just identified — common goal. If you don’t believe it, then give it a try at the next deadlocked meeting. You will be amazed how much power a white board and a marker in hand can create.
Why am I writing this? Well, Scrum has this at the core of all of it’s meetings. In Scrum we have four different meeting types. Sprint Planning meeting, Daily Scrum, Review and Retrospective. Usually each of those meetings is moderated by the Scrum Master. It might be moderated by someone else but it is always moderated! The medium to write on are either index cards or PostIts which are aranged on a white- or corkboard. Those cards are then updated and rearranged during the course of the sprint. A very visual way of management. Alistair Cockburn named it accordingly: Information Radiators.
Next time your are stuck in a non productive meeting just get up and start to use a marker and whiteboard. Everyone in the rooom will be grateful.
The future is Lean Agile.
PS If you are interested in a simple way to moderate a meeting then try out Edward de Bono’s Six Thinking Hats

Pomodoro Technique

About one and a half years I made a huge mistake. A mistake which cost me lots of productivity. One and a half years ago I read about the Pomodoro Technique and was excited about its approach. I even printed out the free PDF. My mistake was to totally forget about it. So never read the PDF and did not learn about this great technique for too long.
Since I read a lot of books from The Pragmatic Bookshelf, I was surprised to see that they published a book — The Pomodoro Technique Illustratedabout this powerful approach. So, I got the book read it over the week-end and finished with the free PDF from Francesco Cirillo on the following Monday. Reading about the Pomodoro Technique was a great and enlightening experience. I come from an agile background and do agile software development since 2001. First XP and then added Scrum by 2004. In my professional life I do Scrum trainings and agile coaching. So, it was great to see the similarities between Scrum and the Pomodoro Technique. It made perfect sense to me from the get go.
Well, needless to say that I am a convert now. Being a consultant, I am often on the road at customer sites and only focusing on one thing. However, between projects or every couple of weeks I am working at the home office for a couple of days. During those days I have to work and catch up on many different things in a short time frame. In the past it was hard to get going and keep the overview. Too many urgent tasks, and at the end of the day the feeling that something important was forgotten. Pomodoro Technique to the rescue. Know I keep an Activity Inventory up to date and on my office days I go through that list and identify the most important ones, either by date or by priority. I get about 10 Pomodoros done in one day. At the end of the day I reassess what I was planning to be, were I actually am and how I could improve. With that in mind I go into the next day.
As I had mentioned, there are some stunning similarities between Scrum and the Pomodoro Technique, here is a list of how I compare them.
Scrum             Pomodore Technique

Product Backlog Activity Inventory List

Sprint Backlog To Do Today List

Sprint Length Pomodore Length


Review Assessment at the end of the day


Retrospective Assessment at the end of the day




I can only stress how effective the Pomodoro Technique has proven to be for me and I would recommend it to anyone who has to juggle several tasks in parallel. If your are an agilist then applying the Pomodore Technique should be rather easy.
Ring …. 25 minutes over – 5 minute break and then of to my next task.

Are you Ready Ready


I’ve been to the Scrum Gathering in Munich this year. In his keynote Jeff Sutherland describes how he gets Scrum teams hyper productive. Essentially, you need to get your stories to Done Done as fast as possible. However, often too many unknowns do exist when a user story is being played. To fix this problem Jeff introduced, as on of his key ingredients, the concept of Ready Ready. Ready Ready removed disruptions and waste caused by issues being clarified with customer or others. He even suggested the use of a Ready Ready checklist to make sure that stories to be implemented do comply with the definition of Ready. Looks like the ‘Definition of Done’ gets a sibling — ‘Definition of Ready’. The enforcement of DoR helped to increase the flow of stories to the anticipated state of Done Done and thereby increasing the productivity. Applying Ready Ready was core to create hyper productive Scrum teams. It came 2nd after ‘Everyone must be trained in the Scrum framework’.
ScrumReadyReady

This is essentially what I have been doing or better trying to do in my last projects. However, the Ready Ready idea is very easy to explain and very convincing. Especially since it comes from Jeff Sutherland.
From now on my Product Backlog items will be Ready Ready before they can move into the Sprint Backlog.

Discipline == Habit

From Wikipedia:
Habits are habituated routines of behavior that are repeated regularly, tend to occur subconsciously, without directly thinking consciously about them.
Self-discipline refers to the training that one gives one’s self to accomplish a certain task or to adopt a particular pattern of behaviour, even though one would really rather be doing something else. For example, denying oneself of an extravagant pleasure in order to accomplish a more demanding charitable deed. Thus, self-discipline is the assertion of willpower over more base desires, and is usually understood to be a synonym of ‘self control’. Self-discipline is to some extent a substitute for motivation, when one uses reason to determine a best course of action that opposes one’s desires.
—————————————
Agile is a low ceremony process which, according to the Agile Manifesto, favors individuals and interaction over process and tools. So in agile we try to use the least amount of process to achieve a certain goal; usually the success of the project. The good thing about high process environments is that you don’t really have to worry about what to do, you don’t even need to grasp the big picture. Just follow the process and the stated rules. Training and ramp-up time are low. Sounds good? In theory it does, however, in reality many cases fall between rules and are therefore not covered by them. Ever talked to a overwhelmed person in a call center because your situation was not in the handbook? Often, I feel that they could help but won’t as they are not authorized to make the call. Agile approaches this problem by moving authority from higher up — the rule writers — to the individuals actually doing the work. Command and control becomes leadership and cooperation. This autonomy comes with a price; (Self-)Discipline. People in charge need to be able to put trust into those empowered individuals. With discipline comes a certain behavior. That behavior and its outcome builds trust over time. Like in Spiderman when uncle Ben told Peter Parker: ‘With power comes responsibility’.
So far so good. This will work great for as long as you stay in the comfort zone. What happens if unexpected events cause chaos and distress? A classical social behavior is that you yearn for something proven and trustworthy. Usually, it is the habit that worked (at least you think) in the past. In no time we forget about our responsibility towards discipline, we are driven consciously or more likely subconsciously by our habits and run with them once more. Worse, this often causes the situation to become even more dire and the vicious cycle is started.
How can this be avoided? In a typical software project, there are three ways that change can be enacted.
  1. A pool of talented employees go out on their own and secretly implement the new process (they know management doesn’t like them to step up).
  2. Management orders that a new process is being used. (command and control)
  3. Both of the former combined — employees and management want to improve together (leadership and collaboration)
The first two options have a very slim change to succeed, albeit the first one is somewhat better off. Usually good people stick to their conviction and let management talk. However, there is only so much pressure they can take. (You can change the company or you can change the company — get my drift)

As for the management ordered approach, I see two possible outcomes:
A) Management is curious about agile and sees a potential silver bullet in it, so it decides to ‘do’ agile and then will flip to next silver bullet once the first clouds appear.
B) Management is convinced about agile and therefore would not only mandate, but facilitate the successful roll-out with trainings, on site consultants and other resources. This brings us the last option of the three.

In the third case management and the employees have the same strong believes and are not willing to give up easily. Open communication and cooperation between those two parties allows for frequent adjustments. In case of shifts in fundamental assumptions, it even allows for changes to the underlying core process . Those adjustments, another agile principle, reacting to change over following a plan, make it possible to keep up with a discipline. Also, disciplines are not cast in stone, they are not dogmas. Feel free to adjust a discipline. However, those changes should have a strong cause and be revisited after an agreed period of time to assess their effectiveness. Often a change is only temporary until another problem has been mitigated.
Over time, with continuous repetition, a discipline will be morphed into a habit. Don’t expect this to happen quickly, it most likely will take month if not years. Once you have been lucky enough to experience this for real, you will be transformed for life. Suddenly you have a clear vision and understanding you never imagined possible. There is no going back.

It is all about drinking the KoolAid once! That’s what turns a discipline into a habit.

Business Analysts are Important

I’ve always been convinced that User Stories are the way to describe feature requests. It just felt natural. IEEE 830 specification are just too ambiguous. Use Cases, even far more verbose, are often too large by covering all possible flows and exceptional cases. User Stories just fit the bill.


Writing good User Stories can be a daunting exercise. A proven way is to use the
AS A persona/role
I WANT goal
SO THAT business value

template with which the User Stories become much more tangible and more important of value to the customer. Watch out for ‘and‘ or ‘or‘ in the I WANT section, those often indicate a second User Story.
So far so good, but this still leaves the acceptance criteria out of the picture. Acceptance Criteria are a good guideline for developers to make sure they do the right thing right. It gives them a change to cover themselves with proper unit tests. QA also uses them as a testing foundation. Most important though, they are the definition of development done. (see ‘Measuring Progress‘) Sure, the customer still has to like and accept them!


So that brought me to use:


GIVEN context

WHEN event

THEN expected outcome


With those kind of user stories you would think you are in pretty good shape. Well, you probably are in the remote case should you develop a programming tool. What does this mean? The more the development team knows about the problem domain the better they are off. Now, consider the case that you develop software for the financial, medical, nuclear or any other foreign field. Looking at the image below you are ok for as long as you stay in the green band where the requirements are clearly understood. In case of the mentioned programming tool your programmers will.
PrjCom

Once you enter the red band, the team enters an unknown and not well understood territory. The User Stories might read like this.


AS A wombut

I WANT to blabalam amplituded chromioms in a shamaluk

SO THAT I can implotude the defused mobolobs


Makes any sense? If you are post-doctoral wombut it will. So, how can this knowledge be transfered to the mortal world of developers?
One option would be to have the wombuts and developers spent long hours together so that they get some understanding about the domain. The more knowledge is missing the longer it will take. Most often, however, wombuts are so busy that they can only spare an hour here and there. There might be some short hallway chats; but often those rise more questions then they answer.
Over the long run, this will lead to an information deficit and the resulting vacuum will be filled with assumptions. Don’t assume — if you assume you make an ASS of yoU and ME 😉
DevDomainConstraint

In the world of TOC (Theorie of Constraints) you can mitigate a constraint like this with introducing a buffer. The buffer enables you to be productive even though a upstream step is blocked. What could this buffer be? As the title already reveals, it would be a Business Analyst (BA).
DevBADomain
Having a Business Analyst will give you two things. First, knowledge you can access all the time; usually the knowledge of the BA is a subset of the experts but in general good enough. If the BA does not know an answer or isn’t sure, she will follow up with the domain expert and report back and grow her knowledge by doing this. Second, the BA can help to bridge the communication barrier between the developers and domain experts. She is used to work with developers and understands how they think. Still, the lingua franca between both sides would be the User Stories with their acceptance criteria. If both the developers and domain expert are happy with the resulting User Stories then we have an agreement about how the customer value will be delivered.


What about the blue vertical band on the requirement image from above? The green/blue area is a well understood domain but is technically challenging. Think about the really fancy programming tool mentioned before — for that strong programmers will be able to do the job. The red/blue area is when you need both; a BA and real good programmers.


Considering I lead a project in the plain red area (not red/blue) and I had to choose between a real good programmer or a BA, I would opt for the BA without hesitation.