Wednesday, July 31, 2013

Don't Miss Retro

Scrum is a very lightweight development methodology.  The idea behind scrum is to be as lightweight as possible with maximum communication.  There are a few meetings to be had in scrum, but only a few...10 minute daily meeting of all team members, 30 minute demo per sprint to all stakeholders, 30 minute planning session at the beginning of each sprint and a 30 minute retrospective at the end of each sprint after everything is done.

I've heard comments from teams over the years where people tend to complain about some it is the biggest waste of 30 minutes in the whole process.  I think the reasoning behind this is that teams tend to re-hash the same topics over and over again and they never seem to get resolved.  I can see the frustration with this, but not discussing issues doesn't make them go away.

Here are three things to try for more effective retrospectives:

1.  Get Everyone Involved

Retrospective should never be the scrum master or the resident nit-pick rambling on about how bad everything is.  It has a format, and it should be followed...every time: Did Well/Do Better/Stop doing.

I see retro's deteriorate into 'What went well?...hmmm...well, we worked really lots done...that was good...'  This isn't helpful...atta-boys come on payday. 
  • Encourage everyone on the team identify the one thing that works that we need to keep doing, and discuss if it's possible expand into other areas to improve other areas.  
  • At the very least, get everyone on the team to suggest one thing that the team could improve on to be more productive...creativity is critical here.  
  • Be critical of process and get people to examine one aspect of the process that everyone just does without thinking that doesn't really provide value and discuss ditching it.
Agile teams are intended to be self managed.  A manager's job is to ask questions like these every day, so it's now the team's job to do do it.

2.  Time Box The Meeting

Get someone on the team to mark the start time and stop abruptly at a pre-determined stop time...even if you are in the middle of a heated debate.  The meeting should never exceed 30 minutes, so do some quick math before you start to determine each member's time slice and stick to it.  If more discussion is needed on any topic, add it to a 'parking lot' list and set a time for another team meeting at least 24 hours earlier.  Give people a chance to think about it and time box that meeting too.

I've seen retro's go on for hours as finer points are debated which just adds to team frustration when things don't improve.

3.  Set Goals

Make sure that when the team comes up with an action item, it should be tied to a desired outcome.  Don't just set rules for the team to follow that don't add any value.  Ask yourself, 'Why would we do this differently?'  If you can't come up with a measurable outcome, then perhaps it isn't something that the team should consider.  This is harder than it sounds at first, but it will come with practice.

For example, someone on the team suggests "I've noticed that we all work through lunch and don't take a break...I think we should start to take lunch break every day."  While there is no doubt that this is a good rule to follow, the team should look at the reason this is important in terms of value and try and measure it.  Perhaps the team feels that taking a lunch break will make for more productive afternoons.  Perhaps the team feels that taking a lunch will make the team happier and less 'touchy' in the afternoons.  Whatever the reason, identify it and make it a point to review the 'outcome' as opposed to the 'input' to measure the teams success at self management.

I would even go so far as to say that the retro item be re-worded to say 'Improve the mood in the afternoon by taking lunch break every day'  This may even give another team member an idea of something to try to 'improve the afternoon mood'.

Saturday, April 27, 2013

Too Much Focus - Why Leadership Needs a Broad Lens

People need goals to solve problems, not suggestions.

Consider an organization that builds cars and has problems with the cars that they make consuming too much gas. This overconsumption is making them inefficient, smelly and otherwise poor quality which is impacting their brand and losing sales.

The leadership needs this overconsumption problem solved, so they begin collecting information on how to solve this problem. After research and thorough investigation, they realized that when you drive too fast in one of their cars, you burn more gas. The leadership asks the team how to keep people from driving the cars too fast. They found the simplest solution is to attach a 2x2x4 inch block of wood to the bottom of the gas pedal...a governor of sorts. This 'governor' would prevent the gas pedal from being fully depressed and would effectively reduce the speed that the car would go. After running some tests, they found that indeed, the blocks made the cars go slower, burn less gas, run longer and cleaner and improve the overall quality of the experience...just at a slower pace.

Problem solving at its finest, the leaders begin communicating how the cars go too fast and burn too much gas to the team and that these new wooden blocks are going to save the company from certain disaster. It's hard to argue with the speed/overconsumption logic and of course the test data is right there, so work begins and cars start getting shipped to go slower. Perhaps this will prevent the gas consumption to some degree, nobody is arguing that...but then nobody is really looking at the problem anymore. Instead, innovation gets applied to the problem of how to put the new block/pedal assembly in place as efficiently as possible and save money on this new innovation.

I call the goal of applying the blocks to all the gas pedals an input goal.

OK, I may be guilty of oversimplifying here, but you get the point. We have been taught that as leaders we need to quickly identify problems and just as quickly drive down solutions and get some action. How much innovation did we leave on the table here? Perhaps the guys that build the engine have known for a while that the air intake is too small and needs re-design. Perhaps the guys that make the body know that the material they use is much heavier than it has to be. Perhaps the wheels are too small. Maybe our speed hungry customers climb under to remove the wood blocks from the gas pedal when they get home and wonder what the heck we were thinking.

A good leader will likely keep asking questions and uncover all of these innovative solutions, but a great leader will help the organization understand the problem, set a high output goal and encourage everyone to drive towards it. How about instead of telling the team to apply wooden blocks, we challenge them to reduce fuel consumption by 50% and see what we can come up with.

Tuesday, April 24, 2012

On Managers and Leaders

One of the areas that is sometimes hard for people to grasp in agile development in the role of management and leadership.

In scrum, teams are meant to be self managed and self organizing.  If an organization can foster this, then it gains the ability to scale, and scale big.  If a team can drive itself to come up with ways to improve, establish methods and conventions that are predictable and repeatable, respond to and award good practice and behavior, discipline bad behavior and communicate status consistently to internal team members and stakeholders, then the team is doing pretty much everything that a manager would do.

Essentially the team is telling itself 'what' it needs to do and 'how' the best way to accomplish this would be.

I once heard that good management in forestry is picking the right size trees, taking good care of the equipment, cleaning up after yourself and not letting yourself get too tired.  Leadership in forestry is climbing up the tallest tree, looking around and yelling down to everyone "wrong forest!! we need to be over there!"

Leaders on teams guide the team to what they should be and where they should go, not necessarily how they should go about getting there.

Saturday, April 7, 2012

Dealing with NFR in Agile

It seems almost daily now, I have discussions about non-functional requirements in agile.  How do we get them into the backlog?  Are they stories like "As a developer, I can run tests so that I know if I coded it wrong"?  What about when we realize that we're storing the users password as a cookie to make it easy for them to log in, and the CSO issues the sermon of "thou shalt not store passwords anywhere..."  Do we add another story that says "As an application, I have to get the password interactively from the user on login so that I don't give the CSO a stroke."

Non-functional requirements are not the same as user stories, so don't try to shoe horn them into the process.  They are never 'done' in the sense of a user story, because they are implied on all features of the product and must be implemented as such.  Non-functionals are defined in the team's "Definition of Done" which must be driven by a clearly defined quality model that is shared between all developers, QA, architects, UE/UX and owners alike.

The quality model defines specific areas that a feature which is "done" must conform to.  You don't even have to come up with your own, there are lots of these on the web, a quick wikipedia search will refer you to a number of really well written documents that all really point back to an ISO standard of quality which contains Reliability, Usability, Security, Efficiency, Maintainability, Portability and a few others.  All of these items have to have targets and benchmarks for how your software will be written.  All projects should start with this definition, which is hopefully standardized within your organization to some degree.

Once you have this definition of done agreed to by all parties, then you can keep you backlog a pristine list of features that your customers will love and not muddy it up with techno-babble about performance tests, deployment support, accuracy, yada yada yada.  All your stories will have tasks to address the quality aspects of your features and the team will take these into account during the planning of each sprint.

Wednesday, September 28, 2011

The Yagni Principle

There are a lot of reasons why we do things in software development, not the least of which is that somebody somewhere will find what we're doing somewhat useful which in turn will differentiate us from our competition and earn us money.  Too often, I find developers working on features that 'may be useful in the future,' while the truth is, the fancy code will likely rot before it becomes useful.  Before you write something, think of the possibility that You Ain't Gonna Need It (YAGNI).

Developers can easily come up with shiny new features, but development takes time and resources, introduces risk and complexity and doesn't necessarily add value. Not always does a re-work of architecture to accommodate some future requirement constitute a good idea.  Ideally, a proper architecture would allow us to defer implementation decisions until they are needed without impacting the existing product.

A simple principle of development is to write the simplest thing that could work. I've seen lots of applications and frameworks that do everything imaginable, but usually at the cost of simplicity.

Does this mean that I think we shouldn't plan for future requirements?  Absolutely not. In fact, I would say that all developers should architect in a way that allows for future development, just leave the details for later...when someone asks for them...and is willing to pay for them.

Friday, September 9, 2011

A note on craftsmanship

Considering that the lion's share of software development costs is spent in maintenance, doesn't it make sense that the up-front investment should be spent in making sure that maintenance is as low cost as possible?

Often times we are driven by project timelines and drop-dead dates only to be saddled with a big lump of unmaintainable code.  I've been doing some reading on software craftsmanship and admittedly, some things make you wonder if the tedium of 'extract til you drop' and 'test first' are worth the effort...after all, it seems that some things could potentially double the initial development time.

If 75% of software lifecycle is in maintenance, and 25% is in initial development.  Suppose I double my initial development; if my maintenance is costs are cut in half, then I've saved about 12.5% of my overall cost of development.

25 * 2 + 75 *.5 = 87.5%

If I can reduce my initial development by half, but it doubles my maintenance costs, then it will eventually cost the organization an additional 62.5% more than it had to and as much as 75% more than it would have if I had just spend some more up front time making code maintainable.

25 * .5 + 75 * 2 = 162.5% + 100 - 87.5 = 175%

Easy math for the brass.

Friday, August 5, 2011

Keep your (over)head down

One of the most challenging areas to address when working in an agile environment is managing overhead.

Anyone who has actually read the agile manifesto can tell you that agile favors collaboration over process because process is expensive and time consuming, and in the end, nowhere near as valuable as collaboration.  This doesn't mean that you don't follow a process in your organization, this simply points out that when one of these two elements has to give, it must always be process.

My preference in scrum is one week iterations, especially when the requirements for a project are vague.  The reason for this is because vague requirements equals blurry vision and blurry vision usually equals frequent changes in direction.  I was told recently that the problem with iterations that are too short is that the overhead is too high; by the time you get out of all those planning meetings and demos and scrums, you don't have any time left to do actual work.

The jury is in on shorter iterations, and the verdict is widely accepted.  The obvious solution is to reduce your overhead...starting with much shorter meetings with fewer attendees.  After that, collaboration then becomes a much more intimate, and in my opinion, a more effective experience.

I can tell a team is forming when I frequently see one or more developers standing over the shoulder of another developer looking at his or her screen with two or more sets of index fingers pointing at something on the screen.  I like to refer to these sessions as a huddle; it is where the 'how the heck are we going to do this?' get's done.

I like to try and separate the 'what' from the 'how' during the development process.  The what involves the whole team.  Everybody on the team needs to know what is being done so that they can adjust their actions to best accomplish the goal.  The how is best determined by the ones that are actually doing the long as it fits in with the bigger what that the team is working on.  Planning meetings that include the whole team should focus on what and stay away from how.  In most if not all cases, 80% of the team will not need to know how things are done, and if they do, then they can hook up with the right team members off line to work this out.

Every time I feel like a meeting is dragging on, it is usually because we have gone too deep into the how portion of the topic or worse, complete digression into useless background information.

Aim for:
Daily Scrum - 10 minutes max
Demo - 30 minutes
Sprint planning - 30 minutes
Retrospective - 30 minutes

The tough one here is obviously the 30 minute planning session, some have said that the sprint planning meeting is time-boxed to 4 hours, suit yourself.  Keep in mind that this meeting is to basically create the sprint contract, not solve all the problems that the sprint poses.  Problem solving meetings are best done in the huddle and only with the team members that are actually implementing the solution.  You may have a need to periodically have a more in-depth planning meeting, I suggest every four sprints perhaps do this.

Keep in mind that this is a guide, take as much time as you need, but remember to stick to what and stay away from how.