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.

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

Business View, Learning and Evolution

Viewing IT project [howsoever small] as business projects is one of the fundamental shifts that we as a team have noticed since we have been exposed to agile methods.

Earlier we used to treat all projects from purely technical viewpoint, not considering enough the problem what we are trying to solve from business perspective. Our role as solution providers was about how we implemented a cool AJAX feature; used service oriented architecture or used n-tier architecture successfully. Rarely, if ever did we consider that will the system attract many users, will users browse beyond the first page, would search engine bots come to the website and get so confused that they would never index more than 5 pages. All this has changed ever since clients have been sitting next to us as we develop and the focus has been on people who will use the system to do the tasks rather than on “users”.

Another offshoot of the business thinking has been to plan activities using concurrent design methods from first sprint itself. We do not optimize the website for search engines/ usability only after the website development is over. It is an on-going process. Although it means that something does not get built overnight, but when it does, it’s generally robust and scalable.

We do however realize that we can not possibly get everything done at the outset itself. Some things you learn only after the system has been in use. However, we are happy that we are on a cycle where we do learn it each time and have something new to contribute every time. It keeps the team morale high and the client is more than delighted. Now only if we could learn to get there just right enough each time and on time, it would be great.

Release Planning and Business Value

Is it important to think of Release Planning in the same breadth as Business Value? Our readings and discussions over the last week seem to suggest – Yes.

Generally speaking, a release can comprise of one or more sprints/ iterations.

• Can we make an assumption that a sprint really is a release?
• Can we release something every sprint? Also, is release a product release or just a demo to a client ?

Like all Agile Development practices, it seems that the idea of keeping track of sprints and releases separately has its origins in product development. However, it also seems true that all the projects can probably benefit from this not so subtle difference. Even in these days of software as a service [http://msdn2.microsoft.com/en-us/architecture/aa699384.aspx] the importance of planning a release can not be overlooked. Release planning really is just a collection of stories organized in order of priority and bunched together so that each such collection can be released [i.e. end users can start using the website]. The sprint however is just a collection of stories that the team hopes to complete within a given time period. However, even at the end of a successful sprint you might not have a product or software that you can release for use by potential users or subset of users.

This is where Release Planning comes in. The emphasis of release planning is business value. The team should not think that a sprint and building features by priority is enough to give a business value. The business value comes from getting users to use the software [or probably want to use the software]. Anything else, no matter how organized and dynamic an environment it creates, does not work from an Agile perspective.

Agile Estimating - Part D

I posted the Part C of this series on the SCRUM development yahoo group. There was in interesting discussion on the same in the group. The general crux seemed to be:

1. Team do not generally over estimate. If anything they underestimate. There may be some minor variations depending on recent experience of teams with some clients or features [using Atlas AJAX framework with dot.Net 2.0 takes more time] or team composition [our lead QA just resigned and new QA would take time to understand features and functionality].

2. Generally, all successful teams have a common minimum time that they would take to do a particular work. The fact that others bid lesser than this, does not mean they are able to do it in less time.

3. Sometimes, the teams might have past experience or know of a smart way to do things, that makes them able to bid lower than competition

4. Organizations can bid lower on a large project which would have many change requests and variations during the project, making up for any low bid. There may be projects where total final cost to the customer.

5. Some truly lean organizations can have low overheads and better programming frameworks like RoR which help them develop software at better quality and faster.

However, the fundamental question I am trying to answer is how do you reconcile competitiveness [quality at a price I presume] and profitability. Some of the suggestions regarding the same are as follows:

1. One is to offer a contract where the client pays per iteration. After each iteration they choose whether to keep going or stop so rather than locking them into a 6 month or whatever project they can stop if they are not happy after 2-4 weeks. That way the sunk cost is lower and their deadline is ages away so they can give the job to someone else with little problem. Usually 1 or 2 iterations is enough to convince them to keep going though. [from Dave] But none of the projects like Youtube, Google or any other successful project had full functionality in the first go. So one should underbid, but not on price but on functionality. We should do what agile does best: deliver an utterly minimal system that still meets the PO goals in the shortest amount of time. Stress the fact that they could be seeing results in as little as 3 weeks into the deal.

2. Emphasize the quality aspect of Agile teams, any past knowledge by which you can demonstrate how going Agile helped a project in the longer run would at least bring customer to the negotiating table.

The problem (or requirement) with [1] is that you need to orient your proposal more towards how it will help the customer to get some basic features out first. You will truly need to get into customers requirements and uncover the risks that a fixed price project would pose. Preferably you can convey that a minimal risk does exist, but you manage to tweak the requirements so that you’re really the only party that can sensibly deliver anything suitable at all. That way you don’t have to compete on equal terms on the bid.

The problem (or requirement) with [2] is that you need to manage knowledge internally very well. Not only should you demonstrate how your past knowledge in a field would help you suggest/ build a better product but also demonstrate how it has helped you do so in the recent past. The difference is important to realize.

Having said the above, it is also probably important to realize that not all customers are good customers and there are some you could do without. Whether or not a customer fits this bill is something that only a particular organizations context determine. On most customers, you need to work on making them understand why you recommend going Agile and T&M basis.

It is also important to have the right people articulating this message. A sales staff that can tell customers to go to hell in a way that they look forward to it is just ideal.

Agile Estimating - Part C

A client recently remarked to us - “You have made us very expensive. I lost a deal when the client came back and told me that you are twice as expensive as your competition”. You obviously wonder, how are others able to do things in half time? Why are we not able to do it? And because we are not able to do it, we can’t estimate lower as well? Then how are others able to estimate lower and complete it in less time as well?

Is it a factor of more efficient developers or cheaper resources or both? Efficiency would probably be a factor of the quality of resources and whether or not can they help us [team/ organization] become successful. However, if we consider that developers themselves would be efficient/ profitable without any organization commitment and involvement in the same, we would be missing an important parameter in the analysis. How do we make a fresher a productive/ efficient resource? Do organizations make/ break people into bad or good performers by their culture?

Agile focuses on team empowerment and responsibility. The idea behind the same is that people who are near to the core of the problem would be best able to do a particular work best. Organizations should focus on an empowered, charged, learned, learning and motivated workforce. The above are also the part and parcel of the culture of an organization. An organization that does not take competitive edge as its mantra can not succeed in the long run. Its the quality that counts and decides metrics for productivity and efficiency. Quality comes from quality people - the best talent is attracted by the best talent and it performs in the right environment.

When we talk of estimates, we must also talk of organization culture and competitiveness. The best method to do the same seems to be continual learning/ empowering of the teams to define a culture that makes it competitive. Its not client’s business sense that Agile teams needs to embrace but organization business value needs to be factored into their performance as well.

Agile Estimating - Part B

We have been trying a new technique over the last few weeks with regards to our estimates. Rather than get an expert comment on how long they think a project will take [in number of hours] we have been asking them to estimate specific activities in the project:

a. Business analysis - the scope of effort in a project is described and documented. This includes prototyping, wireframing, use cases, stories, backlogs and occasionally technical specification documents
b. Development - how many developers for how many months
c. QA - How many testers for how many months
d. Graphics designers - how many design elements/ design scope and how many designers for how many months
e. Project Manager - scope of the project/ timelines and per month time to spent by the PM

This has made our estimates go up by at least 80%. Of course most of our clients do not see the bright side of right estimation at present. We are trying to find the right kind of clients. Of course, we have yet to ask the question - is the right estimate how much time we think it will take us or how much time it should take us.

Agile Estimating - Part A

<a href=”http://del.icio.us/post?url=&title=” mce_href=”http://del.icio.us/post?url=&title=”> <a href=”http://reddit.com/submit?url=&title=” mce_href=”http://reddit.com/submit?url=&title=” >

Agile estimating is supposed to be a democratic and simple process:

1. Write down some user stories
2. Get a group of people together
3 Explain [if required]
4. Play a delightful planning poker game
5. Estimate in story points
6. Apply a conversion factor [derived historically]
7. Compile the points

Details of the software are available at http://www.mountaingoatsoftware.com/ and the game itself is available in a web based version at http://www.planningpoker.com/

So, why is that despite a Business Analyst leading the Agile Project Management movement in our organization, we still have estimates that go wrong horribly? Here are some ramblings from the internal cogitation in the mind:

1. Fixed price estimates: Agility and fixed price estimates seem very different from each other. Agility is responding to change, while fixed price estimates seem to come with fixed specifications as well [well we do know that no specifications ever are going to be final]. One of the suggestions has been to do fixed price estimates with a fixed time period too. I am not sure if that cuts the ice with the customers either who seem to be saying “What can we do if you guys screw up our project and not complete it on time?”

2. Too low time spent on estimates/ proposals: Agility bug has bitten the pre-sales department too. A week is very long time in turning around a proposal especially for low budget projects. Hence, there is less time spent on drafting and importantly discussing the proposal specifications internally and with the client. The result is half baked specifications which go more into how [there would be a text box to allow the users to enter a category] rather than the why. The business process problem/ competitive analysis and importantly domain model - largely stable issues for small budget projects [thereby meaning most of the time small duration projects as well] are often not explored in sufficient detail. An attempt is made to use the historical data for estimating rather than actuals to come up with estimates.

3. Agile environment: An agile environment is very receptive to dynamics of business and requires a very fast response. Fixed price estimates and specifications on which they were based [the same then drives project schedules and milestones] inevitably lead to discussion and heart burn between the team and the client over what is quotable and what is not. This destroys the very basis of Agile - “Customer Collaboration”. After a while the customer distrusts all estimates and milestones, and gets into a bargaining mode.

4. Upfront estimates: Fixed price estimates are always upfront estimates. This means that you generalize everything to result in a utopia kind of environment - average if not perfect developer competence, consistent developer availability, no attrition, knowledge management, code reuse, regular client feedback, no QA issues or regression. This never takes place in a live project. Hence, the idea of a fixed price estimate [upfront estimate] that is ingrained in stone does not seem to work.

Having looked at this, what are the possible workarounds and “art of the possible” strategies for the same? Let’s explore tomorrow or next week …

Explaining SCRUM Basics to Customers - Part I

This week I explained to a customer - what is SCRUM and how to we plan to use it to manage the project [that was currently in progress]. It was the first time someone did this in our organization. However, it was smoother than what I imagined. The customer was more than forth coming and wanted to start with the process right away.

All references to the project and client name have been changed.

Customer says:
what did you have in mind?
Vik says:
We would like to follow SCRUM for Project Management from next week starting with Phase III specifications
Vik says:
you actually have already taken the first step without us asking for it
Vik says:
that is prioritizing the work for us
Customer says:
yes I like the SCRUM model
Vik says:
I think you are familiar with this model – right?
Customer says:
yes
Vik says:
ok – so what we will be doing is giving you a detailed breakdown of list of work to be done for Phase III
Vik says:
please note that this would not cover the work already ongoing on phase II items like labels etc.
Vik says:
which we hope to complete by next weekend
Vik says:
however, we would be starting with work on Monday on Phase III as per priority set by you
Customer says:
ok
Vik says:
we will then track the work on this backlog of work
Vik says:
and visit this once every weekend
Vik says:
or whenever we decide to
Vik says:
and track which items are “done” and which are pending
Vik says:
and then again re-prioritize it on this day
Vik says:
because the priority is not always set and we “might” add more items to the backlog – for instance, the events/ reporting functionality might be higher priority two weeks from now than anything else
Vik says:
does that make sense?
Customer says:
yes it does – I like this model
Vik says:
ok – here are some things which you might be interested to know about”;
Customer says:
ok
Vik says:
1. you can add any item to the backlog at any time
Vik says:
2. however, we will change the priority only when we visit the backlog – this ensures that whatever we take up we complete fully and then move on
Vik says:
3. backlog can have items like “data should be preserved when implementing new functionality”, “the speed should be 1-2 seconds on 56k modem” etc.
Vik says:
4. in rare case if we need to re-prioritize earlier, we can cancel our work and start afresh [however, because we are visiting the backlog once every week – this should not really be the case]
Customer says:
ok
Vik says:
daily status update would be provided to you by team on what they did
Vik says:
also – the detailed task breakdown for the work would be sent to you for each week
Vik says:
I think its important we follow a structured approach because project is now on a critical stage and we need to optimize our growth from scalability, fast turn around times to opportunities and also maintaining a good/ clean code
Customer says:
I totally agree
Customer says:
I think that this is a great approach for V3
Vik says:
Do you have any questions?
Customer says:
not at this time….
Vik says:
ok – if you were to have any questions – please let me know
Vik says:
I am starting a new thread “SCRUM and Project”
Vik says:
in case any one has any questions – you can post them there and I will respond within 24 hours
Customer says:
perfect
Vik says:
however, please note that this calls for a commitment from your side to be available for a weekly chat
Vik says:
this is over and above our other chats we will have
Customer says:
of course – I will definitely make these chats
Vik says:
Thanks Customer. I really enjoyed last 11 months with project and I am sure we would be making a great product in future. At our end, we are committed to help you build a truly world class product.
Customer says:
I am fully aware of that – project is coming along great – we are all very excited about it
Customer says:
Thanks Vik – I look forward to the next level of v3.0 and beyond
Vik says:
Thanks Customer – we are all excited about it as well
Vik says:
Good day ahead
Customer says:
talk to you soon! Thanks Vik

How impressed and excited the customer was evident from the note that he sent us later in the day – “I forgot to ask you guys what day do you think would work the best for us for our weekly meeting?”

What I tried to do was keep this simple and away from jargon. I exposed him to terms like Project Backlog but that was it. There was no mention of Sprints, Sprint Backlog, Burn Down Charts, User Stories, Velocity etc. I think we would need to introduce these terms slowly. It is looking exciting over here.

————————————————————————-
Journey from no-style Project Management to Agile Thinking and Principles
http://agilediary.blogspot.com/