The Purpose of Scrum

I came across a very rare piece of information. It is an article of Ken on “the purpose of Scrum“.

“Work is an ennobling experience, an affirmation of life. In teams, the experience transcends the individual, encompassing the shared experience, providing the basis for team heroics.

Scrum brings order, clarity, cohesion, stability, flexibility and –ultimately – success to projects. In organizations that are coping with how to organize and compete in today’s new economy, Scrum provides a civilized means of rapidly bringing new, complex, high-technology products to market.

Scrum enables people to work harmoniously for their mutual benefit while producing some of today’s must complex, sophisticated products. Scrum is the social engineering of today’s enterprise for the co-operative fulfillment of all involved.”

SCRUM for Marketing

Responding to someone named Dmitry Beransky on SCRUM Development Yahoo Group made me realize that you can use SCRUM pretty much for any of the field. His specific question was regarding how to use it for marketing. Here is what I wrote:

1. Identify the business goals marketing team would have to meet within a set period - say 06 months [remember the goal should be something like increase the leads inflow by 25%, increase brand awareness in Europe, reduce marketing overhead per dollar of profit by 4% etc etc and not attend 10 trade fairs and write 50 sales flyers]. Prioritize these goals. The Marketing VP/ Head can act as a Product Owner for this.
2. The second step would probably be very critical. You will need to break down the goals to achievable steps. You will not probably increase leads flow by 25% in one sprint of six weeks [ideal sprint length]. So you need to break it down to something like 4-5% depending on what you think is achievable. Similarly, do it for the rest of goals. Marketing teams generally need to be very responsive and hence, shorter sprint length would be advisable. However, the marketing results typically take longer to appear - hence, longer sprint length would be advisable from that perspective. Focusing on a suitable sprint length will help you focus on specific goals and allowing the team to aim for those uninterrupted.
3. Divided goals go into specific sprints and now you need to divide goals into activities/ tasks, which will help attain the goal [write flyers, attend fairs, make online presence and what all]. The only difference in getting these sprint tasks is that you might sometimes need to do a planning of 3-4 sprints in advance [fairs might need a stall booking 4 months in advance and getting microsites built might take about two sprints as well]. It is probable that the product owner who can be the marketing VP or similar person sits down with the team dividing the goals into specific activities. Whether or not he assists the team while maintaining their self functioning/ organizing skills, is something the SCRUM Master would need to see.
4. You might have many distributed marketing offices. You might want to check out “distributed SCRUM” thread for more ideas on that.
5. After 06 weeks or whatever your sprint length is, do a review and retrospective and start.
6. One of the key things you might want to see/ keep a check on is the Marketing / Sales is usually a fiercely individualistic and competitive domain. Devising appropriate performance feedback/ results achieved metrics might be useful.

Of course the final advise as is with all the teams I work with - above are just some pointers. These are supposed to help you in making a suitable start for discussing this internally.

However, the above outlines the fact that implementing SCRUM in a non-software environment can be a very engaging experience and would be a great place to be a team, Product Owner and a SCRUM Master.

Time available in a sprint

One of the themes which I get asked most often is, how to calculate how much time is available in a given sprint and to know if someone is overcommitted or undercommitted during a sprint. And its not Scrum Masters, but teams asking this question.

Well lets say the team comprises of four members - Anand, Lee, Sam and Pamela. In addition, there are two part time members - Rose and Kate. We assume there is a two week sprint. A 4 hour sprint planning and 4 hour sprint review/ retrospective means one day of the two week sprint goes in ceremonies. The first step is to ensure every one is available for these ceremonies. Once they are there, you can write down each of the coming working days and check for half day leaves/ full day leaves or other engagements for everyone. You can then note down effective hours everyone has available and do the total. Doing this every sprint can give a “very rough” mapping between hours available and story points burned. Why this approach works is because we are not mapping hours spent and story points burned. As hours available and story points burned are suitably high level abstractions of estimates and planning - this gives “rough insight” for a team to plan.

Another variant of this approach is to try checking how many quarter days each member has available. You don’t know how many hours in quarter days has one available, just how many quarter days are there [in all there are 4 quater days a day]. You can then map the quarter days with story points burned. Similarly, half day approach can be tried.

Both the above approaches are supposed to be used only if team members would want to use them as a rough insight into how much work to plan. This would be probably useful also if the team adds or removes members often, and some sort of rough guidance for the team on time available and story points to be picked up is helpful.

Scrum and not *SCRUM*

Lot of people have been asking during discussions and introductory sessions - is SCRUM an acronym? Why the new to Scrum people get this confusion is because how we spell Scrum - SCRUM. It is not i.e. Scrum is not an acronym. I have been guilty of the same in this blog as well. However, from this post onwards we will spell Scrum like Scrum.

Potentially shippable code - continued

In the last post, we discussed how not to meet potentially shippable code. However, we never really addressed the question as to why is the potentially shippable code that important anyways. It is often argued that the relentless focus on getting to potentially shippable code, is what sets Agile apart from other incremental and iterative processes. This is partly correct. Partly, because there are certain values which Agile stands for and if those are not used for the development, you are not really doing Agile.

Potentially shippable code as discussed in the previous post is always just one sprint away from shipping. Why this is important is because:

1. It keeps the focus on priorities for the customer. She knows that all she needs to do to get the product to the market is announce a pre-release sprint and she will get it. After the first few sprints are done, the incentive to organize the product backlog to develop the product in a manner where it could be released any time focuses product owner to provide value to the project by prioritizing the items based on importance, ROI and risk.
2. The team can think of an iterative and incremental mode of development - with preference to get to overall product structure as soon as possible. In fact is the product backlog has been priorotized well enough, enough value would be got early in the development rather than later, and actually the value added in future sprints could be much less. This provides tremendous ROI for the product owner and again - focuses them on considering priorities on an incremental and iterative level as well.
3. It focuses the team to install engineering practices which will help them get to really done. Some of XP practices like refactoring, unit testing and code sharing help the teams really perform extremely as well as at a sustained pace.
4. Overall, it provides an opportunity to get feedback and adjustment.

One of the tests of whether teams are doing Scrum in Nokia, include reference to “do you provide potentially shippable code at the end of the sprint?”. I have found focus on potentially shippable code really good way to help provide focus for all concerned on product success.

7 Ways to Fail to Deliver Potentially Shippable Code at end of Sprint

Before we address the question of how to *not* deliver “potentially shippable code” at the end of the sprint, it would be interesting to define what is “potentially shippable code“. I don’t know where I read this definition - “potentially shippable code” is only a sprint away from release. Whether or not the code is actually shipped or not would of course depend on does it make *business sense* to ship the code right now or after doing another sprint or two. As you are developing based on prioritized set of features and delivering “potentially shippable code”, you are never far from release. However, you are not reading this blog to find out how to produce “potentially shippable code” at the end of each sprint. Rather, we will discuss how you can through lot of “painful, slow and planned” effort not deliver “potentially shippable code“.

1. Step 1: Do not define Done - Let everyone define what “done” means without communicating on it
   Customer expects to see a tip top UI that functions perfect
   Team is busy building backend and code behind files with lousy UI
   Management thinks the team is building the code that can be supported
2. Step 2: Departmentalize and Compartmentalize work to be done - You have to make sure that work is divided in various departments who can blame each other at the end for a job not done. Here are some steps you can take to ensure that:
   Take Quality out and place them in another department with procedural barriers to collaboration among the two teams
   Do the exact thing with UI designers
   If you can do it, divide the work along horizontal layers like database design, business logic design, interface coding etc – the more you can, the better it is
   Do not forget to add ceremony and processes on how different departments should communicate with each other
   You don’t need to include technical writers, UI review surveyors and other support functions in each sprint – have them learn about your months long project in 10 days and churn up some documentation and reviews
   Doing it last minute and hurriedly without a review is the most important thing here
3. Step 3: Insist on elaborate upfront design documents and architecture designs - Ensure that team worries more about “how they will achieve goals” rather than goals themselves. You can do that pretty easily. Think of the latest modeling techniques and use it to model. Other steps you can try:
   Define all the tasks and their dependencies upfront
   Think about the design rather than what the design should help achieve
   It will help if you can spend a lot of time defining the architecture
   Make developers just Architecture to Code converting units
4. Step 4: Write crappiest possible code that no one would dare to touch in future - This one take special art, after all by the time anyone will touch the code you wrote, you would be in your third job already. Still, you must plan out in great detail processes which help you write the crappiest code possible:
   To ship potentially shippable code, the team not only needs to work on prioritized features, but also maintain a good velocity – so do everything to ruin it
   Write crappiest possible code [no comments, no standards, no reviews]
   Drive developers to guard their code like treasure
   Make developers horrified of others code [success: this was not my code, why should I fix these bugs]
   Make sure your code breaks the build when you check that in and try doing that the last thing in the day
   Make sure your code has low cohesion and high coupling so that any change in any part of code goes and affects totally unrelated part of the code
5. Step 5: Code first and test later and if possible leave testing for another sprint - Who wants to do any testing, thats the lowest possible denomination of tasks in a project. Testing is not as sexy as design, analysis, coding and processes. Also, what value does testing provide to the organization or project. Hence, you should make sure your team treats testing as just a necessary evil that has to be done because processes say so. You should try the following to keep this evil as away and as low as possible:
   Testing should be done at the end of the sprint or if possible in the next sprint
   Make sure you don’t write any test cases so that testers have to go through the code and functionality manually each time they do the testing
   Ask testers to test even the smallest change you make to any functionality
   Make responsibility of testing only the QC departments – you are here only to code
6. Step 6: Change and chop team/ developers - Who wants stability? Management wants flexibility and pre-sales team wants to show developers for new projects. Hence, take as many developers as possible and get new work or shouting customers out of the way. The silent and steady projects mean that they are just too easy to manage and can do with resource snatching. Hence, its important that your developers are constantly changed and chopped between projects between sprints if you want to fail. Additionally, make sure testers, designers etc are changed as well. If you can manage to change SCRUM Masters and Product Owners between the sprint as well, nothing like it
7. Step 7: Make the same mistakes over and over again - This is important. It’s going to be no use if you make the carefully planned mistakes outlined above and then go about fixing them. Make sure you only discuss what’s going to be served in next sprint retrospective and blame every one else but yourself in Sprint Retrospectives. Do not focus on above issues.

If after trying all of the above, you can still produce “potentially shippable code” at the end of each sprint, then please call me. We will create a new software development methodology

Penalities and Agile/ SCRUM - Part II

In the follow up articles to the original article on Penalities and Agile/ SCRUM, I discuss some clauses that can be added to contracts to make it reasonable for both the sides.

• The first thing you would want to do is commit to as less as possible - possibly even just a sprint or a release. Hence, if you do incur a penalty, it is not for much. So draft something like “This deadline would be applicable for only Release 1 and deadline for Release 2 would be provided after Release 1.”
• Approval of all artifacts [including wireframes/ UI and any sprint backlog but not any UML diagrams or architecture] must be done by these dates from the client. To facilitate rapid approval a limit would be kept on the number of revisions for each wireframe and UI. The clients like to add another clause here “If wireframe or UI is rejected, it should not be counted as revision.” This is reasonable as long as the rejections happens in first draft. Any change from xth revision [what so ever you keep] or so - record kept, might be billable at end of project as additional item but not at the end of sprint. Similarly, for any change in approval UI/ Wireframe/ Flow/ Requirement of already delivered/ developed functionality - record kept, might be billable at end of project but not at the end of sprint
• Offer for co-location: It might be useful to bring on this offer [a central Agile principle] to ask the client to depute someone to sit with the team 8 hours a day, 5 days a week and see if we are doing well enough. This is especially useful for large projects with quick deadline.
• You can try committing to the deadline as late as possible. This is useful but rarely practical. However, all contracts are negotiation points and you can bring it to at least Sprint 3 or 4 if not second last sprint. You will have better idea of where the project is going in this case.
• A cap on story points - we will deliver working software by December end as long as total story points for stories remain plus minus 5 percent of 400 story points.

In case anyone has any more ideas, please fire them. We are all ears.

Agile Contracts - Approach Two

We discussed a Traditional Approach to Agile Contracts in the previous post. In this post, we discuss a slightly more Pragmatic Approach, that keeps with the spirit and letter of Agile but you can expect slightly more bickering here. However, its still better than the traditional fixed price approach. So, here is what we have been trying.

• Estimate like any fixed price project
• Make a project backlog - as detailed and as accurately as you can at a time
• Estimate in real time units each item in backlog [no relative units like story points]
• Allow customers to change stories that team has not started working on from future sprints with same weight stories [weightage estimated by the team]
• Provide working software at the end of every release
• Ability to cancel future sprints at a given pre-project cancellation fee

The only real problem that this kind of approach brings is that after the first few sprints, keeping track of what can be taken out and inserted needs a bit more analysis and discussion than a traditional Agile team would like. Another side disadvantage can be to not implement proper SCRUM/ Agile rules [as you are doing fixed price]. Hence, you need to add a fixed time dimension for this which unless estimated carefully can be a double edged sword. The advantage of this approach is that you can readily sell this to the clients and sort of marry Agile with fixed price approach very well. We have started this approach with two recent projects and would like to see how this goes.

Why is SCRUM difficult?

***Draft Version of article

SCRUM seems to be the most light weight method of project management ever. Let’s see what it says:

1. Maintain a prioritized list of things
2. Pick some items and put them in a sprint/ iteration
3. Deliver the items at the end of the sprint/ iteration
4. Revise the list of things to do

Whats it about this that is so difficult to do? Over the last months, we have had difficulty doing this in each and every project.

Difficulty 1 : Drafting a Project Backlog

Project Backlog is not just a prioritized list of things but needs to be prioritized, estimated and also useful/ relevant. Its time and thinking consuming to arrive at a consensus on prioritized list of things or project backlog. It is generally considered a client’s duty to provide the project backlog and keep it useful. The very nature of Agile ensures that he is not the *only participant* in this exercise, nor is this a dump down exercise where product owner just has a field day choosing things. It requires the product owner to answer questions on usefulness and address technical dependencies in the project. It requires the client to be in toes all the time - evaluating usefuless of the items in the backlog and advising the team of business priorities. And importantly it requires the teams to understand this business perspective of the project backlog. For most developers, transition to a business thinking in software development is rare. Software development has generally been considered a technical job, far removed from business and developers/ in most cases even project managers have been shielded from the business side. Hence, arriving at a project backlog that is useful and reflects a common understanding is indeed a difficult exercise.

2. Difficulty 2 : Drafting a Sprint Backlog

Most developers are pretty poor in dividing required tasks for a requirement. It is primarily because they have been fed on a diet of breakdown of tasks already done and specialized people doing specialized work. There is little or no incentive to think about the big picture or overall scenario. Most developers also want to shy away from committments. They would rather have someone else estimate how long it would take and how it should be done. And importantly, most teams are afraid to fail or allowed to fail. SCRUM’s allowance of just enough thinking and ability to add tasks later allows most developers to only think of two-three days at time, giving project managers little by ways of vision of tasks for the sprint. A sprint backlog generally becomes a dead duck document which is passed around in morning email. One day the team is doing 30 hours of work and another only 5 hours.

3. Difficulty 3 : No restrospectives

Most of the problems highlighted above also occur because there is no learning. There is just not enough of committment from the teams side to grow in managing their projects better - not as much as learning a new technology for instance. What is the incentive to estimate better? What is the incentive to divide tasks better? What is the incentive to try an unchartered path, fail and provide a learning of how not to about things? Another problem why teams avoid retrospectives is because most of them do not know how to do retrospectives - what is problem identification and problem solving.

If we do a root cause analysis of each of the above difficulty scenarios - we would reach to one common cause : not enough committment and no focussing on right things. Most of us have difficulty asking questions the right way, analyzing the right way and answering the right way. Most of us are caught up in our day to day working so much that we incorporate only fire fighting element of SCRUM in our project management, leaving the more beneficial - learning and adapting out of window. SCRUM is like driving and swimming - lots of little things to take care of but once you know it, you can do it easily. Unfortunately learning it first time around require : committment and focussing on right things.

Watershed Week Continued

One watershed week followed by another. Can it get any better?

The last week saw us conducting a session for Project Managers and turning skeptics into more skeptics and some skeptics into curious onlookers and some firmly into the SCRUM backyard. The long 3.5 hours session focussed on Agile principles and SCRUM introduction and dispelled many myths. It also gave birth to interesting conversations where insecurity in project managers came to the forth. Further, it also separate the men from the boys and women from the girls. However, the participants do not seem to have grasped all there is to SCRUM. We would need more innovative ways to overcome fear and get a good understanding of SCRUM principles.

The last week we also started a new project called ProjectM. This project would allow us to start a software that supports the SCRUM framework - project backlog, sprint backlog, tasks, team collaboration, obstacle lists and knowledge sharing. I will discuss more details on this project in the future weeks.

Its getting exciting. The real action is starting only now.