Smelser.NET

Whether your following the SCRUM process or not, at some point you've been asked to "estimate" your work. Not surprisingly, the answer to this question often comes in the form of days, weeks, or months. If your providing a Rough Order of Magnitude (ROM) (a.k.a. ball park estimate) for some proposal this may be fine, although this kind of estimation can get you in trouble if you don't add that all-important padding. At this point, your probably saying... Duhhh!... and you surely recognize why. We add padding because we've not taken the time to think about the details.

Unfortunately, it's all too easy to follow this same pattern in Sprint Planning. I can't count the number of times I've witnessed Backlog estimation with the same cavalier days/week estimation approach. To be fair, I've been guilty of it myself and usually pay the price of over-committing myself because I skipping the details. According to SCRUM process tenets, the second half of the Sprint Planning session is dedicated to breaking down "how" we'll deliver the requirements identified in each Product Backlog Item. This is the time for us to think about the detailed tasks that must be accomplished as part of any piece of work. Look around, and you'll find no shortage of guidance on how to structure these but lets see what Ken Schwaber has to say.

While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day.
- Scrum.org (http://www.scrum.org/scrumguides/)

Notice there is no specific number mentioned, although it's implied we should break tasks into sizes no larger than one productive day (whatever that is). This is really clever, because; if achieved; team members can easily assess real progress from one day to the next and be able to both report and observe this progress in the Daily Scrum meetings. If we combine the desire to avoid over-committal with making progress more observable for the team, this seems like a no brainer... Then why do we keep skipping the all-to-critical break-down step? Assuming it's not plain old laziness, maybe we just need some ideas on how we can break down tasking. For me, I often use my definition of "Done" to start guiding my detailed task list.

• Author Code - Try separating your target layers into separate tasks (Ex. Domain Repository, Dal, etc.). This isn't meant to represent a list of classes but it can represent layers of discreet behaviors/functionality. If your developing visual interfaces this could reflect components, user controls, or other visualizations
• Author Tests - As a compliment to authoring the code, create separate tasks for testing each developed layer or component. The previous tasks allow you to report on implementation of required functionality while these tasks allow you to report on the confidence with respect to completeness, reliability, etc...
• Integration - These tasks identify work often required for larger products and may represent dependencies you have on other resources such as graphic arts, localization teams, etc. Additionally, you may also want to set aside tasks to integrate new products and/or components into your build process, source control, and/or CI tool-sets
• Reviews - This reflects interactions you inevitably need to have with other people, and can serve as a nice reminder that you need to coordinate/review material you've authored/updated. This could include things like peer reviews with other developers, component introduction with the test team, etc...
• Deployment - Set aside tasks specifically targeted to implement/update those things you need to deploy your product. This may include installers, configuration profiles, monitoring resources, data stores, etc...
• Documentation - This reflects tasks related to documenting what you are going to do or have already done. This could range from release notes, code documentation, test cases, user documentation, etc... 
• Demo/Review - Don't forget to set aside a task to prepare product scenarios for the Sprint Review/Demo

This isn't meant to be a complete list and I'm sure you can think of additional items. If you think about it, this really isn't hard and making a quick bullet list of items such as I've done above doesn't take much time. Conducting exercises like this may help you realize that your shoot-from-the-hip estimation may not be enough to produce a "complete" product. As an added bonus, this kind of detail in your estimate can really help facilitate discussions with those that complain... "What do you mean that takes two weeks?". As with most things, the devil is in the details, so don't just assume you'll remember them, break them down...

Tags: processes

SCRUM strives to have developers release 'production ready' code with each iteration, or least that's what popular guidance tells us. Unfortunately, these two words can lead to some teams questioning their compliance with the process, or worse, questioning whether or not the process is even viable. I was reminded of this recently when someone claimed they weren't following "real" SCRUM because they always had to wait for testing after the Sprint ended.

Depending on how you define "production ready", you may be setting expectations too high. "If" you can actually implement changes, test, and release them into production with each iteration, then great. However, many shops can't achieve this, and that doesn't mean they're not following the SCRUM process correctly. To understand this, we need to go to the source and see how some popular guidance may have mis-led us. In this case, we need to hear from Ken Schwaber who is credited as one of the main authors of the SCRUM process. Luckily for us he's published the details on this particular issue.

The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
- Scrum.org (http://www.scrum.org/scrumguides/)

If you compare "production ready" and "potentially releasable", you can see the difference. This may seem like splitting hairs, but the expectations for each are different. If you're going to question whether or not the process is viable based on this tenet then you need to make sure you scope it correctly. The SCRUM process doesn't really define what this means, leaving it's criteria and measurement up to the implementor. With that said, the process does try to encourage Sprint definitions that lead to complete features, which is consistent with an iterative approach. This lack of detail is actually a good thing, since it gives us (e.g. the implementors) the flexibility to define a criteria that is appropriate for our environment. Lets face it, if you've worked in more then a couple dev shops then you know the culture related to product releases can be quite varied.

The decision on whether or not to release a product can be informed by a number of factors; many of which can require resources outside the Team. Here are a few example:

• Product Testing (e.g. verification and validation of functional requirements)
• End user acceptance testing
• Security review
• Compliance review (e.g. validation of regulatory issues such as PCI, Privacy Act, Section 508, etc.)
• Alignment with marketing initiatives
• Enterprise integration testing
• Etc...  

Consequently... while the Team may feel they're "Production Ready" it may be some time before the larger organization makes the same assessment. Thinking more generically about testing, lets take a look at a few common patterns seen in dev shops today.

This first pattern represents what would be required to produce an iteration of a product and test it within a single Sprint. This approach requires the testers and dev team work very closely together. Since both are pigs in the same Sprint, communication between the two parties can be very efficient allowing devs to quickly address bugs as they're found. On the down side, the team must reduce their development capacity to stabilize the product earlier in the Sprint life-cycle. For small product changes this capacity reduction can be fine, but present challenges for larger changes. While this may work in some teams it won't be practical for many. Many organizations have dedicated test teams supporting multiple Teams and Products. This makes commitment in any one Teams Sprint less practical, so these organizations may employ patterns that look more like the following:

In this pattern, the dev team communicates readiness for test as features are completed throughout the Sprint. This typically occurs near the end of the Sprint allowing the test team to start building/refining test plans, start testing, etc... In this case, the test team is not a pig, so testing will often continue well into the next Sprint. 

Similar to the previous pattern, this version acknowledges those environments where the test teams first introduction to product changes is the Sprint Review.

No matter which pattern your organization follows, any of these can reasonably; and correctly; be applying the SCRUM process. If the dev team is producing complete changes, based on what was known during Sprint Planning, they're not in violation of the process. So the next time someone says your not following the "real" SCRUM process because of your release schedule, you can point them to Ken. Maybe they can try and convince him.  Good Luck. 

Tags: processes

I walked into a meeting earlier this week, only to find a huge count-down clock projected on the wall. There was no mistaking what this meant... We were going to have time-boxed discussions. I wrote about a similar pattern in my post Your Time is Up, but I've never seen anything quite like this. As it turns out, this tool is called "Big Time" which is appropriate. But the real hidden gem is the voice-over which had a distinct measure of desperation in his voice. As if to say... "I got a Computer Science Degree and THIS is what I am doing?"

With that said, the real credit goes to the my Scrum Master... This worked brilliantly...  Simple and effective... Nicely done Jon. 

Tags: processes

In my last SCRUM-tastic post, Manager Interruptus, I picked on managers a little and blamed them for hampering the teams momentum. As I mentioned, it was a little unfair but it served to illustrate something we all know is true... Despite "your" best efforts, constant interruptions can really destroy your ability to be productive. From time-to-time, no matter what you do, you'll find yourself; or your team; in danger or not meeting commitments. When this happens, you generally have four choices... 

• Cancel the Sprint - If something has happened that is a complete game-changer, then you should approach your Product Owners and discuss canceling and re-planning the Sprint. In Scrum terms this is totally acceptable, although it should be done only when absolutely needed and should not become a regular occurrence 
• Ask for more time - This may work, although it creates a slippery-slope and could have down-stream impacts that may not be obvious to the development team. Putting aside the issue of breaking the Scrum time-box rules, this could impact things like resource scheduling for other team, which is common in Scrum-of-Scrum scenario's often seen in larger organizations. This could impact business commitments to customers or suppliers, which could have costly legal implications. It could effect marketing campaigns which often have substantial investments and may be time sensitive such as holiday offerings. In some markets licensing restrictions may only give a company a small window of opportunity to get into a market, and delays could cause them to miss the window. In any case, since we burned the managers in the last post they probably won't be keen on this for a while 
• Let it fail - I covered this in the last post, and this may be an option in some cases, but is generally frowned upon. Assuming it doesn't require super-human effort, striving for success is often better then outright failure
• Go Dark! - Given the title of this post, I'm sure you guessed we would end up here. This isn't the most ideal solution, but sometimes this is the only "reasonable" option. Lets explore this a little further

When individuals cut themselves off from the team, this could be an indication they're thrashing which is generally a bad thing. In this case, I'm talking about the larger team going dark together for part or all of the Sprint. The goal is to limit the number of interruptions to mitigate the risk of the team not meeting their commitments. Depending on how far the team is behind, you may only need to Go Dark for part of each day or for several days straight. Assuming you can see the danger coming, you should start with the former and only go fully dark if you absolutely need to. The techniques vary widely and really need to be adapted for your team but here are a few suggestions:

Level 1 - Nominate a stand-in

When people start to fall behind you'll often hear complaints about having to attend too many meetings. If this is your case, then you'll need to nominate someone else to attend these meetings and represent the team. The Scrum Master or Team Manager may be ideal candidates for this. Since they are likely aware of your predicament, they should be more then ready to step-up and support the team.

Level 2 - Drop your connections

Whether we like to admit it or not, there are a lot of ambient distractions that tend to draw our eyes away from what we should be focusing on. While it will pain most of us to admit it, our distractions are likely online in one form or another. A few examples include; but are not limited to; the following:

• Close the Browsers pointing to your favorite social networking site, news/sports cast, and/or blogs (except mine of course). At the risk of stating the obvious... you probably shouldn't be doing this at work anyway
• Shut down Instant Messengers... It's not enough to set "Away" or "Invisible". To avoid those attention getting beeps, bleeps and honks you'll need to say goodbye to your friends and loved one's, shutdown IM, and get to work
• Close Outlook, or whatever email client you're using. When you see or hear emails arrive there is a tendency to stop, read, and answer them. In most cases, they can wait a little while
• Disable Mobile device "Push" Notifications. In some ways, this feature should be an indication we've gone one step too far in being constantly connected. Let go of your Twitter, Stock Alerts, Facebook, and Weather updates for a few hours so you can get something accomplished
• Etc...

Level 3 - Keep the lines busy

If you work in one of those shops where people just love calling you, then you may need to unplug your desk line, close your VoIP client, and put your mobile phone in Airplane mode. If you're on-call or still need to be reached by your manager, make other arrangements by having them contact the team through a third-party and make sure these details aren't advertised to anyone else. This could be through the Scrum Master, receptionist, or someone else you can trust to hold-back the flood-gates of distraction.   

Level 4 - Leave the building

This may seem a little over the top, but it may be necessary. We've all experienced those moments when noone was around and we got a tremendous amount of work accomplished. In this case, we're just trying to recreate that experience. One of my old teams liked going to the local coffee-shop for a few hours each day. They had fuel (e.g. coffee and scones), wireless internet (often free), most patrons treated it like a library (e.g. quiet), and most important they had no drive-by interruptions from colleague's. There are many variations to this technique. Assuming you trust your team, they could work from home from time-to-time. You could book a conference room for a long period of time and all work from laptops. In most cases, people will typically avoid bothering people who appear to be in a meeting. Your company may even have other facilities you can use.

At the moment, you might be trying to figure out what you can get away with where you work. Whatever your case, you'll need the support of your Scrum Master and Team Manager. Ideally, they'll run interference for the team to make success as achievable as possible. Even if you disagree with my specific examples, hopefully you can see how techniques like this can be useful in varying degree's. Although I implied this is needed to avoid interruptions from people, it is worth pointing out this can be useful for those high-value last-minute business "requests" that need quick solutions. In any case, give it a think, adapt to your team, and hopefully you'll make it over that hump...

Tags: processes

In the last couple of posts, Dealing with naysayers and Big projects and Epic tasking, I focused on the team members that seem to love complaining. Unfortunately, this isn't completely fair to those that have bought-in to the process and are just trying to meet their commitments. For them, let's turn the discussion to a type of impediment that can make any process or committed team fail... Managers... or at least some of them. Again, this may not be fair, but let's explore this a little more and I think you'll get my point.

For the sake of discussion, let's just assume everyone is bought into the process. This buy-in assumes that everyone knows that one of the key process tenets in Scrum is that once the Team has made a commitment, they need to be left to meet that commitment. Unfortunately, managers are vulnerable to acute cases of amnesia which often manifests shortly after the Sprint Planning session. Whether or not this is truly a medical condition, it can have detrimental effects on the team's ability to stay focuses and maintain momentum. Treatments for this affliction can require a delicate touch and have mixed results, but before we discuss treatments let's look at some of the symptoms and explain how they can affect the Team. 

Multi-Tasking, Context Switching, Task Switching

Some would say the ability to multi-task is a crucial skill for any IT professional. The problem is... us humans just don't do it very well, although many of us think we can. Do a little Googling and read what the productivity experts have to say. Their agreement on the matter is almost unanimous... we often become less productive when we try to multi-task. Managers need to be aware of this more than anyone since they're the first line of defence. Most teams will have some ability to absorb unplanned tasking; which is often represented in the team's productivity rate; but managers need to make sure people don't take advantage of this "potential" capacity.   

Here's the main problem... when someone is working on a task and they're interrupted, it takes them considerably more time to regain the same momentum they had before they were interrupted. This includes drive-by questions, phone calls, email, visits from the manager, and meetings, meetings, meetings. Depending on the task, this can be really costly if the developer has to regain complex or nuanced information before they can restart their work. Some interruptions are inevitable, but constant interruptions can put the team at risk of not meeting their "real" commitments. The manager needs to be aware of the amount of context switching occurring in the team; especially when it's their fault; and work with the Scrum Master to deal with excessive interruptions. Some might say the interruptions need to be "managed", but that's just me trying to be cheeky. 

One reason this might be the managers fault, is based on the typical manager/employee dynamics surrounding delegation. This is fine to a point, but if the managers aren't careful they can delegate the team right into failure. We can assume this isn't conscious neglect. Maybe they're naively oblivious to the damage left in the wake of them trying to be "good" managers... What?... It could happen!... At some point, managers; and other supporting staff; need to become self-sufficient and carry the load without the Team.

Let's just add this "one" more "little" thing...

If your Sprints are the average three week length, there's a tendency to think that with so much time we can add just "one" more "little" thing. This is another famous manager line, but it's a slippery-slope. If the manager wasn't afflicted with 'the illness', they would realize they're asking for trouble; or at the very least, adding risk. The reality is, there are very few "little" things that can be added without having a larger knock-on effect. New stuff; whatever the size; needs to be designed, coded, integrated, tested, documented, etc... Before you know it, the dev has lost valuable time on something that wasn't originally a commitment. As a rule, there should be no new or altered commitments once the Sprint has started. 

Possible Treatments

Communicate the problem - The best thing to do is have a team meeting with your manager(s) and tell him/her what the concerns are. The Retrospective Meeting is a great place to start this discussion. Depending on your relationship with your manager this may or may work, and you may need a more subtle approach. In this case, try reducing your teams productivity rate and subsequently reduce your commitment at the next Planning session. If you keep doing this, your manager is bound to ask what is going on. This will give you another opportunity to articulate how interruptions are endangering your team's ability to meet their commitments. To be effective in making your point, you'll need to have some evidence. As they happen, try adding unplanned/uncommitted tasks to whatever tracking system you're using. This will give you a valuable point of reference and may also reflect on the burn-down chart which can help reinforce your point.

Learn to say "No" without saying "No" - This can be hard in some shops, but may be necessary to prevent the teams failure. Since "No" can be received negatively, try approaching this from another angle. This is a bit Freudian, but it works.

• Start by suggesting the new task be a "priority" for the next Sprint. This sounds like "Yes" but implies a "No" for the current Sprint without saying it 
• Say "Yes" with the Proviso the manager identify what "commitment" should not be done as a result of adding the new task 

Batch your interruptions - As valuable resources, it makes sense that some questions can only be answered by the Team. If you're suffering from frequent drive-by questions. Ask your manager to save them up and ask more questions with fewer interruptions. Maybe he/she can agree to meet the team once a day or every couple days to have a time-boxed Q/A session. For this, I recommend following stand-up rules so things don't take too long. 

Let it fail - No one likes to fail, and I'm not suggesting sabotage. With that said, there's no sense fighting the inevitable. Everyone has to be made aware of the consequence of not keeping the larger commitment to the team. Some Sprints can require extra-ordinary effort, but they can't be planned with the expectation of Herculean efforts on the part of the development team. That's a recipe for disaster. 

This isn't meant to represent a complete list of treatment options, but may give you a few ideas on how to handle this. Whatever you do, try and remember that everyone has their own perspective, and odds are good they're busy as well. In most cases, the problem(s) comes down to communication, or the lack of it. Start with the direct approach, and resort to Freudian manipulation only if you need to. 

I picked on managers a little bit, but the truth is, they're a valuable part of any team being successful. With that said, we can all slip into bad habits and sometimes need to do a little Freudian introspection to reflect on our own behavior. For full disclosure... I've done my share of managing, and I've certainly been guilty of doing things mentioned above. Like anything else, the Team and their manager(s) need to find a balance to ensure the larger business objectives can be met without killing your team in the process (pun intended). 

Before wrapping things up, there is one more thing... What about the Scrum Master? ... Great question!... Since they facilitate every daily Scrum and should be the first to hear about impediments, they should be well aware of what kind of stress the Team is under. Consequently, they should be the first one to tell the manager when its time to back-away and start helping keep outside interruptions from the Team. So get to work you Scrum Masters... 

Tags: processes

In my last Scrum article; SCRUM-tastic Tuesday - Dealing with naysayers; I talked about common complaints heard when trying to employ the Scrum process. As I mentioned, those types of comments are not really unique to Scrum and are often heard when trying to implement other processes by those that don't feel they need any process. There was one question that I purposely left out which requires some dedicated focus.

This work is too large to fit in Scrum.

This brings up a couple separate issues... "push-back" and managing individual backlog items that are spread across many Sprints. The push-back is easily dealt with, by using a little common sense. The naysayer is attempting to suggest that large projects cannot be accomplished using iterative or Agile processes. Assuming they can say that with a straight face, any experienced manager should see right through it. Just take a look at any Gantt Chart for a typical waterfall process and the non-sense should become evident. Even if the decision to use Scrum vs. some other process is open for debate, this line of thinking is a slippery slope and often leads to cowboy-development initiatives which can easily fail, fall behind schedule, exceed budgets, or miss customer expectations entirely.

At the risk of sounding redundant, Scrum strives to have its participants set a short-term goal (e.g. the commitment), allow it to happen, and then retrospectively assess what they have done. This frequent repetition allows its participants to make minor; even major; course corrections based on their experiences throughout the life of a project. But what about larger architectural considerations? Good question... Just because you're working in short iterations does not mean you can't work from a larger architectural plan. Adherence to this plan is left to the Product Owners (or architects) to ensure backlog items are prioritized appropriately before each planning session.

If you're working on a big project you may find that you have backlog items that are either so large they can't be accomplished in one iteration, or represent work that applies to every Sprint. These situations are actually very common in Scrum and have many names (e.g. Epic's, Saga's, Enterprise Stories, etc.). Requirements surrounding compliance with specifications are a common example of this. If you've developed e-commerce sites you may have had to comply with things like PCI, Section 508, OWASP, and others. There is a tendency to make these types of things backlog items although I think this may be a mistake. Generally speaking, backlog items should represent "what" the customer wants. These types of requirements are really constraints on "how" it will be implemented. This may seem like splitting hairs but there is a reason for this line of thinking.

The problem (or at least concern) is backlog overload or making the "process" become the product rather than focusing on prominent features. If Product Owners keep presenting the same backlog items over and over again, these items can take valuable time away from consideration of more substantial feature-sets during planning sessions. This can start to turn into white noise, and pretty soon no one is really paying attention. I'm not suggesting specifications aren't important, I just think they should be planned and dealt with in a different manner. I like to think of them as "constraints" rather then backlog items. These are things that shape "how" the developer will implement "what" the customer needs. Constraints are a natural part of defining "what" is needed, so it shouldn't seem strange to add them to a given User Story.

This is a bit Freudian, but the goal here is to keep the main focus on the larger User Story as apposed to any one constraint and the smaller the number of stories in planning the more effective your meetings will be. To make up for any concerns related to not making specs a first class backlog item, try making your specifications a focus-area in your test plans. This gives you visibility into overall compliance and will be a continued reminder for everyone involved.

No matter how you decide to manage such requirements, these concerns are not really unique to Scrum, or any other Agile process for that matter. With that said, the Scrum process does provide a framework which may just make it easier to manage within your team. If nothing else, these considerations may just help you do a little push-back of your own on those naysayers.

Tags: processes

No matter what process you try to implement there is always one constant... "Naysayers"...  What is a naysayer?

One who frequently engages in excessive complaining, negative banter and/or a genuinely poor and downbeat attitude. ... They have the capacity to rant and whine for hours on end about the most insignificant inconveniences.
- Urban Dictionary (http://www.urbandictionary.com/define.php?term=naysayer)

We've all heard the complaints and they generally follow a common theme:

This process won't work for "our" kind of work.

This is a common misunderstanding. Aside from Scrum largely being a development process it is not prescriptive with respect to the type of work being undertaken. This process can be applied to graphic design work, engineering work, testing, product releases, defect resolution, etc. The process makes no mention of any one technology stack, operating system, application type, style of development (e.g. peer-programming or individual developer), etc...

This kind of task can't be estimated.

This is another common misunderstanding. Scrum does not require an "estimate", but it does require you project a time-box around everything you are setting out to accomplish (e.g. the commitment). This helps manage momentum and prevent failures from spinning out of control. More importantly, this helps prevent things from going unseen by those that have to manage the project and manage customer expectations. Essentially, you set out to accomplish something over a given period of time, then come back together at the end and reassess. Scrum is an iterative process and repeats as many times as needed to deliver the required results. 

There is too much paperwork. I'm a developer, not a tech writer.

There are two problems with this... First, Scrum is a very lightweight process with respect to artifacts and has no specific requirements surrounding the fidelity of artifacts. If you have really complicated or overly detailed artifacts you can't blame the process, blame yourselves or your company. I have witnessed many shops managing their work with a wall of sticky notes and that's as simple as documentation gets. Second, developers who think they never have to write anything down are kidding themselves. Putting the obvious design and requirements artifacts aside, in the real world businesses need to be able to capture certain aspects of product development in writing to protect and maintain their investments. 

This process slows us down. We could work faster without it.

I love this one. This is the notion that if the management teams would just leave the developers alone, developers would be more efficient. Truth is, working in total isolation seldom leads to any real success. Putting that aside, the Scrum process demands very little from its participants in terms of time. Besides the daily stand-up meeting; which is only 15 minutes long; the only required meetings are the Planning Session, Demo/Review, and Retrospective, and these only occur about once a month. I can't think of too many professions that can really claim so few meetings. Heck, I had more meetings in a week working as a kitchen slave in France.

There are plenty of others, but you get the point. So when this happens what can you do? Unfortunately, there is no "one" answer but there are a number of patterns that can go a long ways to helping:

• Be consistent
  • Once the team has decided on how it will implement its process, do not allow deviation. Do not sacrifice schedules or milestones. The team will need time to settle in and see the forest through the trees. In the mean time, you need to keep them on track... even if it hurts. Use the retrospectives at the end of each Sprint to introduce changes over time
• Be pedantic
  • Don't sacrifice the details. This may not make you any friends but you have to be the details police. Avoiding this creates a slippery slope and before you know it, no one will be following the process
• Get unequivocal support from the management team 
  • Although this can be tough for some, you can only be successful if your management team is totally committed. They need to be stead-fast in their commitment to those charged with implementing the process. If there are concerns, take it offline, and do not argue in front of the team
• Let them make the process their own, but don't compromise on the tenets
  • Every team has their own quirks, and may have ideas that will work very well for them. Assuming these ideas do not sacrifice the basic process tenets, let them choose their own details. If they feel a sense of ownership, adoption will be much easier. With that said, they need to understand that these ideas will be subject to all the aforementioned points

Well, thats it... Hope this helps.

Tags: processes

If you've worked in a Scrum shop for any amount of time then you already know that momentum is the name of the game. If Scrum had a mantra it would likely be something like... "Just get on with it...". This can often translate to a sense of urgency, and depending on your perspective, it can be a good thing or a bad thing. In many ways, this straight-forward mantra is what attracts some people to this process, although without proper management you can quickly lose momentum and burn people out. Don't believe me? Google it, if yee doubt the claim.

Do a little reading and you will quickly find the consequences of these conditions can lead to lost productivity, reduced quality, and more often then not valuable people quiting. To make matters worse, techniques to combat these conditions can be quite varied, depending largely on the personality of your team and/or individual team members. Putting that aside, lets try and enumerate some practices that can help mitigate some of the aforementioned concerns.

Intellectual Spiking

In my experience, developers tend to be some combination of artist, scientist (sometimes mad), inventor, and for some... masochist. While we can't cater to the last one we can do something about the former items. If you think about it, there are always things the team wish they could work on. This could be new product ideas, technology exploration, graphic artwork, animations, design patterns, etc. Assuming these projects are not too far off the track, side projects can go a long way to giving developers something to look forward to. If you do a little research it is easy to find plenty of examples of how these types of projects can often lead to huge successes for companies, so this is not all that crazy.  

Invest in Automation

This section could easily be called "Repetition is Evil". Monotonous tasks will absolutely drive devs crazy. While this could be an entire article in itself (note to self), the message here is simple... get rid of the drudgery. This not only makes people happier, it can lead to huge cost savings for companies by letting devs work on more productive tasks, and can lead to huge increases in quality and capacity. Here we are talking about letting teams adopt new tools, build Continuous Integration infrastructure, testing rigs, deployment routines, etc. Some companies may wince at the thought of shelling out a couple grand on new tools, books, or whatever, but anyone who knows anything about this business will tell you it is usually worth it.

Mix up the Roles

This can be tough in some organizations but can really produce amazing results when viewed from a teaming perspective. In this scenario, we are taking someone out of the normal commitment pool which can be a bit of a break by itself. Instead, we can rotate the dev through a variety of other roles. This can be used to help people see each others position from a different perspective which can lead to a better appreciation of what each role provides to the others. Here are a few examples:

• Change places with the Scrum Master: It can be tough running between teams, organizing your own team, dealing with conflict resolution, facilitating meetings, making on-the-spot decisions, and meeting the individual demands of each and every team member. The Scrum Master can be the unsung hero and everyone should spend some time in their shoes
• Become one of your users: This is a great shadowing technique... Send some time in your users shoes and you will usually walk away with a better sense of what works and what doesn't. This can be a great motivator for improving products, enhancing usability, and keeping a dialog between the devs and end-users
• Be the support monkey: Most teams have some kind of support burden which is usually impossible to estimate. Take one person out of rotation and let them answer these calls. This can relieve the pressure for others and provide everyone with much needed visibility into things they may not have written themselves. Between calls, they can start picking away at open or lingering bugs, or take care of other housekeeping issues 
• Become the enemy: If you have products that are really concerned about security... Spend some time trying to break into your own system. This can be eye-opening and fun

Rethink your productivity rates

In a previous article (SCRUM-tastic Tuesday - Estimation guesswork) I discussed the notion of a productivity rates. This is the number of hours per day each team member is expected to be making progress towards the completion of committed tasks. This tries to acknowledge time spent on the phone, answering emails, attending meetings, training, lunch, etc... No estimate should extend beyond this number. If people are consistently frazzled by the end of the Sprint, then you may need to rethink your productivity rate to give people a little more breathing room. If everyone is always rushed, defects and/or implementation compromises will start to develop which; in the long-run; can be very costly.

Embrace your pain-points

Each team knows what they are, and usually know how they would address them "if" they were given the time. Let them do it. If something is holding your team back then it makes sense to let them deal with it.

Share the "New" work

There is just something pleasant about creating your own project from scratch. While you may be constrained by team or organizational standards, you are not constrained by having to reverse engineer a lot of Intellectual/Technical Debt. When new projects arise or old projects lead to creating a new set of libraries, solutions, etc. share the wealth.

Don't forget play time

I have never been part of a dev shop that only worked 9 to 5. Developers work long hard hours, and they need a break just as much as anyone else. There are lots of ways to support this, and companies that understand this will usually get a better return on their investment. Ideally, you want to give developers time away from their desks but engaged in something together. Depending on your corporate and/or team culture options can vary widely. Here are a few ideas...

• Send the team to a nerdy conference like TechEd, Code Camps, or designer events
• Send the team out for a night on the town. This could include, dinner, concert tickets, and maybe even drinks
• How about team paint-balling... Let them get rid of some of that aggression. This works best when they can challenge the management team
• Sponsor a game night. This could be a giant Halo event using corporate projectors, a few bean-bags, poker, Uno, or whatever. Buy a few drinks, pizza, and taxi-fare and let them have some fun

Hopefully, this provokes some thought about how you can manage some very costly concerns. Trying weaving some of these ideas into some of your Sprints and you may just have a happier team in the end. As a side note, the issues presented above plague many Agile processes within the development community so feel free to adapt your reading accordingly. With that said, this article is titled "SCRUM-tastic".

Enjoy...

Tags: processes

In my last post SCRUM-tastic Tuesday - Estimation guesswork, I proposed a simple approach to estimating work and managing expectations. After the post I got a few emails about the value of the Delphi Estimation method. Specifically, the writers mentioned the anonymous collection of estimates as the only real way to see how close or how far apart people see the size of a piece of work. Here is a basic summary of how it works:

• An assigning manager approaches two or more developers separately and describes a single unit of work
• Each developer estimates the work as they understand it and submits their estimates anonymously to the manager. Neither developer knows about the other and the manager does not know which estimate came from which developer
• The manager reviews the estimates. If the estimates are more than 15-20% apart the manager calls a meeting to discuss the difference between the estimates
• After the meeting, the developers re-estimate
• This process repeats until the estimates are within threshold (15-20% in this case)

This sounds complicated but it does work. This forces people to explain why they saw things so differently, often leading to the discovery of assumptions and/or risks observed by one that was not considered by the other. This approach also addresses the issue of peer pressure. We have all seen it... Put the team in a room and ask them for an estimate and often you will only hear from a few people. Unless those few people are doing all the work, you may have estimates that don't reflect what the actual assignee can commit to. This kind of communication can go a long way to ensuring your estimates reflect real concerns. 

In a Scrum environment, the problem is time. The aforementioned process takes a lot of time and orchestration, which Scrum shops don't have. There is however another process that strives to capture the value of the Delphi method while prescribing a process that is fairly lean with respect to artifacts and time. Its called Planning Poker.

For me, this process gets to the heart of the matter, which is forcing full participation. The process is simple:

• Bring all the devs together. Just like Delphi, explain each unit of work and ask the developers to estimate using numbers provided on a set of cards
• Everyone shows their estimate card at the same time allowing everyone to see each others cards
• The facilitator will be able to any see big differences immediately and ask each person to explain the assumptions and/or concerns reflected in their estimate
• After a round of discussion, the team estimates again, repeating if needed

This process can go very quickly and provides all the same value as the Delphi method, although the artifacts created in this process often have a much lower fidelity. Strictly speaking, the cards are not critical... You could just as easily use yellow stickies, as long as the value choices are the same. Personally, I like using one of the many IPhone or Windows Mobile apps for this (Ex. Space Flight Orange).

While the previous example focused on dev shops this process is a great way for team managers and product owners to do rough estimation ahead of the planning sessions. This allows each party to get a sense of which pieces of work are larger or smaller and can guide selection of priorities. In this case, they are not trying to nail-down detailed estimates; instead; they are trying to define a rough approximation (often in days). This is also known as a Rough Order of Magnitude (ROM) estimate or a ball-park estimate.

Technically speaking, there is a little more to the process so feel free to read up on it. Whatever you decide to do, just remember, the most important part of getting reliable estimates from your team is getting people to communicate... chickens and pigs.

Tags: processes

Whether your using Scrum or some other Agile process, at some point you will be asked to Estimate your work. So what is that... as if you didn't already know: 

The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion.
- Wikipedia (http://en.wikipedia.org/wiki/Estimation_in_software_engineering)

The truth is; unless you are building templated software like toys on an assembly line; good software estimation is generally some combination of experienced guesswork, historical evidence, dumb luck, and black magic... If you are using processes that require higher fidelity artefact's like CMMI, SW-CMM, etc... then you may be familiar with estimation practices like COCOMO, Delphi or others. If you are working on very large projects, or you need to do long-range estimation, these techniques can make a lot of sense.

In Scrum, you have roughly one working day for the business to articulate its needs and priorities for the next iteration. During this same time the Team has to figure out what they will commit to delivering, how they might do it, who in the team will do it, and how long it might take. With so little time, traditional techniques just aren't practical so the estimation priorities need to be shaped accordingly. A key practice in any project is proper management and communication of expectations, risks, etc... So with that in mind, here are the tenets of our estimation process:

• The artefact should be quick and easy to produce...  Keep it simple and reuse your tracking system if possible, letting the assigned task list represent your teams estimate (Ex. TFS, Microsoft Scrum, VersionOne, etc...). It could be as simple as a spreadsheet or even an email to all concerned
• Communicate where the team has a lack of confidence in their estimates and why. Managers can use this to get a sense of how much contingency;if any; they need to add to an estimate to ensure customers are not too disappointed if things go the wrong way
• Communicate what risks, resource shortfalls, or impediments the team is concerned about. This would include things that could place the teams ability to deliver commitments in jeopardy. Generally, these are items that need to be addressed by Product Owners or the Scrum Master
• Communicate any assumptions the team is relying on as the basis of their estimates. This would include things that; if not true; could dramatically change the estimates

This may sound like a lot but this can be done very easily... Here's a sample of a spreadsheet that demonstrates each area:

As you can see, this would take very little effort, allowing the team to spend more time talking about more important details. On the other hand, this clearly communicates the points that shape expectations.

Even if you get the estimates correct, there is still one element that can cause you to estimate incorrectly and technically speaking this should be done before you estimate. What is it?.. Defining your teams Capacity. Essentially, we need to make sure we don't over-commit the team or any one member of the team. This process is pretty straightforward and does not require much more then a white-board discussion. Here are some things that should guide this calculation:

• Will any member of the team be taking a vacation or any other planned time away from the team?
• Are there any company holidays?
• What is the team's productivity rate? This is the number of hours per day each team member is expected to be making progress towards the completion of committed tasks. This tries to achnowledge time spent on the phone, answering emails, attending meetings, training, lunch, etc... No estimate should extend beyond this number

Hopefully these tips will help make your estimates a little more successful.

Tags: processes