Managers in Agile

One of the challenge and opportunity that transition to Agile presents for most organizations, is to redefine how we manage things [and we saw in last post - how difficult it can be] and importantly the role of a manager.

Well, below is a general outline of some of the things managers do in their current roles:

• Do code reviews
• Define tasks
• Assign tasks
• Track tasks
• Firefight
• Make MS Project Plan
• Make Excel Reports
• Talk to the customers
• Give feedback to team members
• Recommend appraisal of team members
• Promote team members
• Give presentations
• Train people
• Write case studies
• Write white papers
• Work with other teams
• Provide technical leadership
• Provide process leadership
• Provider marketing leadership
• Do HTML coding or other housekeeping work
• Keep customer happy
• Read about technology and trends
• Make usage projections
• Improve company bottomline
• Recommend engineering practices
• Control attrition
• Interview and hire
• Provide status updates

There can be more depending on which organization do you work with. All that is needed is to come up with all the tasks that you do and cross out ones you should not do in Agile. Assigning and tracking tasks are obvious ones to go. There are many above that can be crossed. After this, investigate if any more things should be added to the mix. Thats it - you have a great new JD for a Manager. CMMi - here we come

We do not know how to …

A lot of people come to me these days and ask, ever since we started doing Agile, things have gone from bad to worse. Some of the things that go wrong [according to them] are:

• We do not know how to bill - the customer wants a fixed price while we can’t give it in Agile
• We do not know how to hire - there are so many things we need to look for more, we can’t seem to find enough people
• We do not know how to train - we need to coach people on things like responsibility, duties and collaboration
• We do not know how to measure - how can you measure without knowing what everyone else did
• We do not know how to manage requirements - they just keeping all the time and we do not know how to keep architecture scalable for that
• We do not know how to manage - Agile just throws so many things in diverse directions and we do not know how to go about things

My first response to this is “Ok! At least you know all this and got so far”. Invariably I find out that the reason they are unable to manage the above is because they are able to somehow manage to do the impossible - reinvent the wheel on Scrum and XP. Probably its the comfort of familiar rather than uncomfort of unfamiliar, although that may turn out more comfortable. Needless to say there are many solutions available for the above. We will try and see some of them in the future posts.

Agile Manifesto - Values

As discussed in the previous posts on potentially shippable code, its not just the iterative and incremental development that sets Agile apart from other development frameworks. In part it is its focus on getting to potentially shippable code at the end of each sprint but also the values it emphasizes. These values are best captured in what is called Agile Manifesto. The signatories of the manifesto include Kent Beck [creator of jUnit and originator of concept of Design Patterns], Martin Fowler [originator of the concept of Refactoring], Dave Thomas [wrote the landmark book on Agile Development with Rails], Ken Schwaber [co-founder of SCRUM] and Brian Marick [world renowned testing expert]. Agile Manifesto states that:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles behind Agile Manifesto were as follows:

• Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

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

Should managers worry about extended coffee breaks?

I firmly believe that most organizations would run better if managers managed a bit less. The problem is that most managers do such a horrendous job themselves and drive others to do horrendous job as well, that if they did not manage at all, things would be better themselves. And they should definitely try and keep themselves away from SCRUM teams or should I say “fully functional teams.” And this means doing these [and much more]:

• Not keeping a count of how many coffee breaks a person takes
• Not keeping a count of how much time ABC spends on phone
• Not raising an eyebrow seeing an employee sleeping on the desk

Its sometimes also called reactive management. In fact I dont call it reactive or proactive. Its just another style of management and pretty effective one IMO for you can focus only on results and the behavior which drove the results. In case you use Agile, you can ruthlessely focus on results every two weeks or so. This allows for self correction in teams. Self correction driven through self introspection and committment to try out new things for better results seems to be a better driver for well, better results. Is that not what the management wants in the first place?

Here is why focusing on behavior first is harmful. Lets take the example of server administration teams. Lets say the server administration team [they do a great job and thats probably why] sit idle most of the day and only mostly answer email or do jobs which are completed in 15 minutes flat. Once in a while they are busy like hell, taking back ups and what not, but mostly you find them reading hacking articles, blogging, networking and boasting. There is another team with 3 developers [who do more than some 6 member teams]. However, you find most of them in canteen, laughing, blogging and in passionate discussions. CTO just passes by and after three such sightings can not control and makes this sarcastic mark “So you guys have outsourced your work too?” Managers wandering by and making sarcastic remarks about outsourcing, or whatever half-assed other smart comments they may make, demonstrates management inability and lack of awareness. Frankly, the manager should hope to see those ’slackers’ always ’slacking’, because that implies there are no server administration problems happening, which has to be a good thing.

IMO you need to avoid looking at the slacking [for instance] even if it is in your face. If you are doing Agile, what you need to look at it is what was committed [and assuming this was reasonable commitment] and what was delivered. You can obviously ask question like “What made you miss the commitment?” Slacking can be one answer and Low Morale [because of a manager just walking past and seeing team engaged in tea 5 times a day and remarking sarcastically, have you outsourced your work] can be another too. The managers job is to unearth the behavior for poor performance and not “seemingly” poor behavior itself. However, day after day we see poor management results [sliding profits, non paying customers demanding bug fixes and holding teams hostage, poorly trained teams] due to management proclivity to focus on trivial and urgent but not on important but not so seemingly urgent. It makes you realize how ingrained “command and control” is in our mindset as managers. The notion of a self functioning team just does not exist. The underlying assumption is that they will surely do something wrong and when that something wrong does not happen [well obviously because they would not commit to a 45 man months of work in 5 months, which management wont have any qualms over committing to by the way], issues like longer tea breaks, too many training sessions, not pushing too hard, there is an easier way to do this work, bottom 10% need to go, appear.

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 vs. Waterfall - Convincing Clients

Dave Barrett, Lawyers’ Professional Indemnity Company provided this delicious recipe on how to convince clients for Agile.

“We can set a deadline if you like. In that case, we’ll spend the first month of the project working up a scope document and bouncing it back and forth between our two companies making revisions and additions until we hate each other. After that we’ll treat the SOW as gospel and fight like hell against any changes. Any additions to the scope will push the deadline back weeks at a time. Since you’re almost certain to add to the scope, this means that you’re doomed to miss the deadline even before you start. You won’t actually see any results until a day or two before the(revised) deadline, at which point you’ll almost certainly be disappointed because certain features won’t work the way you envisioned, or won’t be included because you never told us about them or didn’t know that you’d need them. We’ll then work up a new SOW for phase two of the project and rinse and repeat.”

“On the other hand, we can have short meeting tomorrow, identify the couple of features that seem to be the most important right now. Then we’ll get the Team going on it and show you what it looks like in a couple of weeks.Then you can pick the most important things that need to be done next and we’ll work on them right away. It may or may not be possible to get the system finished by your deadline, but the Team will always be focused on what you’ve determined are the most important aspects of the software all the way through the project. Our experience is that you’ll have working software faster with this process, you’ll waste less time and money building features that you don’t need, the features that you do get will work just the way you want them to and you’ll still like us at the end of the project.”

What do you think the customer will choose?

Discouraging Waterfall contracts

I know thats a rather sadistic title for a post but I could not help write the same. For the purpose of this post, I consider Waterfall as “fixed scope” project more than a reasonable length [4 person man months and over should quality I guess]. Here are some things you can try [some have worked like magic for me]:

1. As bad as it sounds, add even more ceremony to your waterfall contracts. Add initial requirement list sign off, each requirement gathering iteration sign off, method of estimation sign off and what not. Try to get sign off on exact process, SLA, bug count, delivery dates, feedback latency and all the abstruse things any one can think of. If that does not help, announce that after subjecting the poor client to 1 month of requirement gathering and contract revision, you plan to spend another 3 months discussing the project itself. The above time zones [1 month, 3 months] are relative for say a 6 month project. If that also would not work, try adding clauses that favour development unit more than the client - “All UAT must be done within 2 weeks of getting the build and the like.” Add costs for any allowance the client requests. You will either loose the business or get an opportunity to push fixed cost/ fixed time but variable scope projects. If you can just send an email newsletter singing paeons of Agile just at right moment to get the clients in right mood to talk.
2. Disguise Agile Completely. Here is one approach:
   • We understand initial requirement define a fuzzy viewpoint on the horizon. Hence, we allow our customers to add requirements at any stage and delete/ edit/ replace items from the requirement list as long as it is of the same size, size determined by us.
   • We would provide you working software every iteration [basically 2 weeks/ 2 months] free of cost/ at additional charge of XX USD per iteration.
   • You can cancel the project at any stage for a free of XX USD in case your business interests are met earlier due to working on prioritized business requirements
   • We welcome client feedback and this would be managed as per attached Annexure [Annexure is more glorious description of SCRUM/ Agile].
3. If the above slightly cheeky ideas don’t work for you, you can simply do case studies of projects done using Agile [also do customer satisfaction studies] and show how going Agile is good for business [faster time to market, lower cost of ownership, flexibility to respond to business changes] etc.

Penalities and SCRUM/ Agile

We have converted quite a lot of our projects and teams to Agile which is great. The teams are happier and delivering value to customers. However, one area where we have a problem is with new customers.

New customers appreciate and value the flexibility Agile offers but would like to stick to a deadline [October 15 or December 15]. We always advise and agree them that this is a central part of Agile - aiming for delivering maximum functionality by given deadline. However, what is a problem is that they take the release date as being a bit too literal. They would even like a penalty for not completing the project by given date. And these are pretty knowledgeable clients who are pretty reasonable otherwise. We try and reason that with ability to prioritize, shelve and add features that Agile offers, this kind of clause is not possible. However, it does not cut much ice with them.

We have tried to convince management to add a bonus clause [if we meet target we would bill at higher rate and client will finance holiday for whole team]. Surprisingly the clients agree to this and the ball is back in our court. Further, the teams internally do not want to go in projects even with lure of bonus and no amount of convincing helps them. They say they can commit to the deadline only if all UML and prototype diagramming has been completed and signed off. This gives us ideas and scares of waterfall ghosts.

As always, its an interesting problem to have and something we need to plan out on how we would approach.