1. Make a business decision without consulting the partners in the business.
2. Find a buffoon who has never heard of Agile and make him Project Manager.
3. Task the Project Manager with making the business decision a reality, using the Product Owner’s team.
4. Don’t brief the development team or the Product Owner on the situation.
5. Put a distance of half a continent between the Product Owner (and team) and the Project Manager.
6. Watch as the Project Manager drowns the Product Owner with outdated waterfall documents and processes.
7. Watch as the Product Owner tries to stay afloat and keep the Scrum process happening.
8. Watch as the Project Manager contradicts himself as he struggles to employ waterfall properly.
9. Watch as the Project Manager fails to understand even the basic principles of Agile methodology.
10. Watch as the Product Owner struggles to meet the waterfall requirements in the Scrum environment.
11. Watch as the Product Owner lacerates himself on the rocks at the bottom of the waterfall, pulling the team with him.
12. Watch as the Project Manager follows his Gantt chart like a blind man with a guide-stick, and tries to demonstrate the product which wasn’t made to the company owners.
13. Listen as the Project Manager points fingers, blames, attacks team members on a personal level, and tries to play the Scrum Master against the Product Owner.
14. Listen as the Scrum Master gives in and allows the Project Manager to dictate deadlines and content of sprints.
15. Watch the mutant team stretching themselves around ’scrumfall’ methodology.
16. Listen as the Project Manager burns everyone’s ears with stories of his own success.
17. Watch as the team grows hatred for the Project Manager.
18. Watch as the Product Owner abandons the company.

Did I mention the word ‘buffoon‘? It doesn’t feel right to limit the description to a single word, but, as I’ve learnt, using many words to describe nothing is one of the traits of such a person.

Scrum has Sprints, Scram has Scrambles. We scramble and push and do everything we can do deploy new functionality every day.

Humans and animals move fastest when running from something, not when running towards something.

In the case of Scram, developers are running from fear of being booted from the team, losing benefits, and losing respect. They are in an effort to ‘keep up’ with the best of the team.

Scram is like an olympic-level of development.

The purpose is to get the most out of the team, to push them beyond their usual capacity, and to meet their needs as we do so.

Let me start by just getting on with it.

I know ‘deployer’ is not a real word.

Requirements for Scram:

• A team consisting of: A tester, a deployer, 2-4 developers, and a product manager.
• Company-provided lunches of salad or pasta and varied meats (chicken, beef, pork, seafood, fish – 5 days, 5 different meats).
• Company-provided refreshments available whenever the team needs them (water, tea, milk).
• Company-provided fruit/berry snacks.
• A product to create.

Abnormal focuses:

• Nutrition of the team
• Pressure-cooker mentality
• ‘Natural selection’ evolution of team – the chaff gets booted out quickly.
• Team-members control who is in the team.
• Paired/quartet-programming encouraged.
• No documentation (unless documenter is added as a separate entity to team)

Normal focuses:

• Working towards a common goal.
• Test-driven development.

Roles:

• Tester – Works between developers and deployer. The tester is responsible for testing ‘completed’ work, and giving the go-ahead to the deployer. Developers must inform tester when work is ready for him to test. The tester is responsible for deployed, not-working functionality.
• Deployer – Works between the tester and the product manager. The deployer is responsible for deploying work which the tester approves for deployment. The deployer is responsible for broken deployments. The deployer maintains a deployment record for the product manager.
• Developers – are responsible for creating the product. Developers must understand what functionality needs to be made, and then make it. Developers must inform the tester of work which is ready for testing. Developers are responsible for work which fails testing.
• Product manager – is responsible for itemizing and detailing the functionality to be created. Is responsible for providing goals. Is responsible for released product.
• Documenter (not obligatory) – observes tester and story description from manager, and documents functionality.

Iterations:

Daily routine:

• 15 mins preparation – manager explains what tasks are ready. Developers recap what tasks are in progress.
• 120 minutes development – Major effort. Coding, testing, deploying can all take place.
• 15 minutes recap and preparation – developers explain what has been done, what is yet to do. Tester explains what’s tested. Deployer explains what is deployed and/or will be deployed. Manager observes.
• 60 minutes development – Medium effort. Coding, testing, deploying can all take place.
• 120 minutes lunch – extended lunch. Team should eat together, discussing work and patting themselves on the backs. Stragglers have time to catch up. Impediments and problems are explained to the manager.
• 15 minutes recap and preparation – next phase is planned, deployer recaps, tester recaps, developers recap, manager encourages.
• 120 minutes development – Major effort. Push to get something deployed if nothing new is deployed yet.
• 15 minutes cooldown – Patting-on-the-back, recap, discussing problems. Each team member confidentially writes two names: team member they were most impressed with, and team member they were least impressed with, for the manager’s review.

The manager’s daily routine is somewhat different:

• 15 minutes preparation – manager confirms with team what will be achieved today.
• 120 minutes development – manager reviews yesterday’s work and communicates with stakeholders.
• 15 minutes recap – manager learns the current state of development.
• 60 minutes development – manager plans and predicts outcome for the end of the day.
• 120 minutes lunch – manager joins in, discusses with team, jokes, keeps the atmosphere positive. Glares at slower team members.
• 15 minutes recap – manager explains progress and expectations.
• 120 minutes development – manager starts to plan next day’s work, based on projections for current day.
• 15 minutes cooldown – manager goes berserk if nothing was delivered. Manager praises team is goals were met. Manager collects feedback from the team.

Guidelines:

• Deployment can be made at any time.
• Something must be deployed every day.
• Extended lunch break. Always.
• Team members can be booted out of the team at any moment, at the manager’s discretion (based on team feedback).
• Team members should be the ‘elite’ and be paid and treated that way.
• Unique hats or t-shirts or mouse or monitor should be given to team members to distinguish them from others.
• Team members can break and snack at their leisure.
• Friday evenings of every fortnight should be a major wind-down, possibly with a trip to sauna, gym, massage, or yoga.
• Strong focus on nutrition; physical and mental well-being of the team members. Team members should start to increase their capacity for output the longer they stay a part of the group. Should also result in less sick-leave, which can collapse Scram.

Business-level notes:

The fact is, running with such a team is going to be expensive. The lunches, the benefits, the ‘elitism’ of their salaries, etc.

However, the potential output, and the fact that new features are delivered every day, gives such an approach a high value – a value which in broad terms can be translated into higher revenue for the business.

Being constantly pushed, reviewed, and judged by their peers can result only in the overal improvement of the team members, and a well-oiled team of intelligent and highly-skilled people should result in a high-speed development process, provided that the product functionality can be divided into components small enough to develop in a day.

It remains a fact that this development approach is not suitable nor required for many common projects. Users of systems rarely require new features available every day. Regardless, this approach can be maintained with releases to pre-production environments, which are then passed on to a Q.A. department for monthly deployments into the real world. The goal remains the same – to create the product as quickly as possible.

A note on documentation:

All products should be documented, and the documentation should be written for users. With Scram, an option is to have an additional team member – a documentation writer.

Flaws:

• Quality of work is never checked.
• Automated tests of functionality are not created.
• Unless the team knows each other well, it can be a free-for-all battle to get the ‘easy’ tasks to work on.
• Scope of stories to be completed is only broadly estimated, on-the-fly.
• Bug fixing has to be slotted-in randomly.
• It’s difficult to find team members suitable for such a high-level of output.
• The manager is somewhat hidden with his collection of feature requests and stories for the developers. For the developers, these may seem to come from nowhere.
• Team members have no chance to make suggestions for features.

http://www.karmaengine.com/_img/daily-routinejpg.jpg

Firstly I should define what I mean by ‘worse’. Well, essentially:

• Quality of code decreases
• Ability to estimate tasks decreases
• Attention to detail decreases
• Time distracted increases
• Work done fails testing more frequently
• Contribution during discussions decreases

I suppose the first step in handling this is to sit down with the developer, a senior developer, and a director and have a good old-fashioned discussion on these points. But this is not going to do much to solve the problems, it’s just going to result in the developer either bawling their eyes out, or agreeing firmly to try and improve matters.

So, more drastic action has to be taken.

Addressing a lack of code quality

A sit-down review with a high quality coder can help. Mistakes and vicious habits can be pointed out, as well as correct principals and other methods. This should be a personal tutoring session and take place every week for a couple of hours. Yes, this kicks eight hours out of our two-week sprint, but I consider that that’s peanuts compared to the damage being done. It’s only the start, though!

Helping with task estimation

Estimating tasks is supposed to be a personal thing – the developers should visualize the process of developing the solution, of testing, of documenting and preparation. They should total the hours they’re likely to spend on these aspects and that should be their estimation. But if the developer has trouble visualizing, or breaking a task into ‘actual things to do’, their estimate will be rubbish.

To help the developer turn the task into actual things to do, it is a matter of simply extending the discussion of the task (prior to estimation) to include or share opinions from others on how they would approach it.

If the developer still doesn’t understand enough about the process to be able to give an estimate in hours, then it’s a problem. It’s a bogus developer who should be asked to re-evaluate his employment in the company. They may require extensive training, but in the case I’m talking about, where the developer has steadily declined, it may be time to put his experience elsewhere, rather on the frontline.

What to do when attention to detail decreases

Details are important, especially in software development – the world in which many finicky users stalk around with magnifying glasses. And, I personally find that when a developer makes the effort and pays attention to small things, that he is giving himself a little golden place in my heart. Obversely, when the developer ‘doesn’t give a hoot’, no matter how good they are, I get a little bit clenchy in the fist region when I see him.

Attention to detail can be increased by embarrassing the developer. Aye, it’s true. Point out his mistakes (even though they may not be technically mistakes) during stand up meetings. Laugh about them, make jokes. Be light-hearted about it, not stern. He will laugh too but watch his cheeks go red. If this continues to happen he will knuckle-down, out of the basic human need to ‘fit in’.

Another good way to make a mockery of a developer is to not single him out. Make a joke to the team that some silly person -did-whatever- and how funny and troublesome it is. If he immediately owns up to being the cause, it is something very respectable.

Removing distractions

I am always of the school of people who don’t want to restrict workers at all in the office. Introducing ‘no browsing’ or ‘no music’ policies is insane, in my opinion. The real way to remove distractions is to make the developer understand that while he’s not working, he is overloading himself in the future, and, since scrum is all about the team, he is increasing pressure on the team.

An interesting way to do this is to speak with another developer, someone who you trust and who you’re friendly with. Tell him or her that you are going to make an example out of them after the stand-up meeting, but only as an example to the other developer. Then, after the stand-up meeting, question your friend about his forum chatting or flickr browsing during working hours. Then directly ask the team how much pressure they’re feeling right now, and if they really have time to waste on non-productive activities. If they all agree that they do have spare time, that’s your fault. It might be a chance to introduce a brainstorming or knowledge-sharing session for them. That would be better than seeing them mucking about on youtube all day.

I also hate checking up on people. Procedures can’t be measured, only results can. But checking up sometimes help. It helps sometimes to just go and look at the developer’s screen. Don’t say anything, just look. They will feel uncomfortable, but since you’re not really putting any pressure on them to ‘get back to work’, they will get a splash of guilt, rather than anger. Pat them on the shoulder when you walk away, too. This is a friendly gesture which means ‘you’re part of the team, I like you’. It is a little condescending, but I feel it’s the right approach.

Reducing test failure

Again, this is where humility comes into play. It’s usually like this: the developer works on his task, tests it on his local machine, commits his changes, and then doesn’t test on the development environment, or does a very limited check to see if the thing didn’t break after his commit. Then he goes to make coffee or unwind his brain from the task he’s finished.

Then someone tests his task and boom. Test failed.

The developer often takes an hour or more to be informed of his failure, then some time to begin working on it again, then time to find and fix the problem, and so on and so on, damaging the team’s performance. Test failed tickets are like a stab wound to the team. They can be fatal.

So – how to make sure the developer fully tests his own work before and after committing? Humility, yes. Embarrass him again. Count up the number of test failed tickets during the sprint and make the developer with most wear some silly t-shirt during the next sprint planning session. Be creative, but not cruel. Make him feel like the other developers are laughing at him. There’s only one direction he can take to resolving it – and that is to ensure he doesn’t have any test-failed tickets in future.

Increasing the developer’s contribution during discussions

There’s not a lot that can be done about this one, except directly asking during discussions for the developer’s opinion. Try to get him involved in the same way you’d try to get anyone involved in a conversation. Ask questions, talk about the things they worked on, and so on.

If someone starts falling asleep during the planning session for example, depending on how horribly mean you are, a sudden clap is quite entertaining for everyone else, and will wake them up.

It also helps a developer feel like a sturdy cog in the wheel if you praise them. And, when he feels like a contributing member, he will act as one.

In the end, it’s essential to remove the ‘dead wood’ from the team’s little bridge, and replace it either by employing someone different, or solving the problems causing the wood to rot. If you don’t, the whole thing can collapse.

Yet scrum has weaknesses.

I can talk about what I have perceived from being involved in Scrum for eleven months as a product owner. I am sure there’s more than one ‘opponent’ of this development method, but I am certainly not of that ilk, nor do I wish to be. I just want to share my experiences.

Firstly, scrum pays entirely no attention to product maintenance and technical support. If you have a small company, with only a handful of developers working on a new release of a product, there’s nobody to maintain the old versions while a sprint is in progress.

The obvious workaround is to reduce the number of developers involved in the sprint, and stick them on maintenance and support handling. Aha- but for a small team pushed to make a new release, this is a disaster. Firstly, a reduced team equals a reduced output, an extended release date, and, let’s face it, less revenue.

Secondly, reducing the team reduces the skill of the team. With less knowledge available to developers, the code quality will suffer tremendously.

With less knowledge, there’s also less knowledge-sharing. If four men can’t change a light-bulb, but five can, then it’s a single man which makes the difference. The same with scrum. Remove a man from the team and the rest of the team will struggle.

Possibly, the team can remain the same size, but with a reduced velocity. Personally, I find that reducing velocity has some kind of negative mental effect on the developer. Reduced velocity translates to – more tasks. More variation in tasks in turn translates into less ability to cope with the tasks. Why? Because it’s difficult for a programmer to switch from task to task. Not only does it take time, but it also requires changing gears in the brain and doing this often leads to increased stress, and lower performance.

A classic case: Artyom (used his real name) used to be a part of my team for the new product release. Then, due to lack of available skill in the maintenance of another product, he was moved to that. That product is developed and supported in an entirely different country. Artyom faced a constant battle with himself to find time to do actual work – he was constantly bombarded on Skype by users and other developers. He would start a task, halt due to a Skype interruption, reset his brain and work on the emergency task thrown at him, receive yet another task in a similar fashion, spend hours explaining parts of the system to other developers via chat, and in the end, he was one very unhappy and underachieving developer.

Artyom said to me that it was not the interruptions affecting him, nor even the explaining which he was doing every day, it was the changing between tasks, which sometimes took him half an hour of saving, deploying, documenting, downloading, merging, opening, understanding, and reading code to understand where to begin, which created the stress and anger.

The same effect can be achieved by reducing sprint velocity. Other, non-sprint tasks will leak in, that’s one of the points of reducing velocity. When the tasks do leak in, there’s a long process required to get the developer to actually start working on it. Then the same process to continue on the previous task. This means that hours can be lost each day, not due to actual development, but due to.. overhead.

Now, the second (or first?) major problem I have found with scrum comes from task planning.

Different teams plan the sprints in different ways, but here’s how we do it:

1. Stories are explained to developers.
2. Developers consider, ponder, think, and divide the story into real tasks.
3. Real tasks are discussed, understanding is reached, and the tasks are estimated, one-by-one.
4. Estimating involves each developer holding up a card to display the number of hours they think the task will take to develop, test, and document.
5. If the differences between estimates are not too great, I take an average and assign this amount of hours to the task.

So, what happens when Mr Estimated Thirteen Hours ends up on a task with eight hours planned? Well, he struggles, he overspends his time, and essentially, spends thirteen hours on it. Well, that’s five hours lost from the sprint backlog. But, that’s the point, it’s not lost, it’s still in there, still estimated to some task, and someone has to pick up the slack.

Not only does Mr Estimated Thirteen Hours end up blowing his workload on red hours (hours spent on tasks outside planned hours), but he pushes to work faster, and his code becomes messy, his tests fail, and he doesn’t care because he has another task, failed tasks, and testing to juggle.

Before I continue I want to quickly point out one more flaw with the way we’re running scrum. Sometimes there’s one or two team members who simply cannot estimate, either due to mental deficiency, or due to lack of understanding of the task. As product owner, I can’t pick up on this. I don’t know if the developer truly knows how to write the appropriate code. If he says he understands what needs to be done, then I have to trust him. The only thing I can do is watch his eyes during estimation. He will be trying to see other people’s estimations before selecting his own.

Estimating.

Yes, estimating is one of the main problems we’re having. We strictly plan the sprint based on the developer’s estimates. With a small team, this can be a fatal mistake. We’ve had several failed sprints which have failed because the team was not large enough to provide enough intelligent estimations.

Essentially the entire release date depends on the developer estimations. If they can’t get it right, you’re boned.

Back to Mr Estimated Thirteen Hours.

He has 56 hours of work to do during the sprint. But he always, always spends 30% more time on his tasks.

He works 56 hours on only 40 hours of sprint tasks. That means at the end of the sprint, assuming other developers stick perfectly to the plan, there’s 16 hours of unfinished work. Scrum has no real way to manage this. And neither do we. We sit scratching our heads in the retrospective, wondering what went wrong.

The only solution: lower the velocity for this developer by 30%.

Now we have a mixed-velocity team. This is against the scrum guidelines. But it is the only solution I can see.

In conclusion, scrum is probably still evolving, you can learn a lot from the first year of it’s implementation at your company, and you have to be prepared to smooth-out the rules a bit, if you want this much-kneaded methodology to fit in your pie tin.

I think we’ll be seeing more web-based applications, games, and Java developments, and less of the standalone desktop type software being created. This seems to be the trend, anyway.

What this trend (whether it exists or not) means is that the move will be towards much more agile development – but what kind?

More on this after I’ve given it some proper thought…