Life, Teams, and Software Engineering

Category: teams (page 1 of 2)

Mission Tracking for Agile Projects

Despite agile methods doing a great deal to bring technology teams closer to the consumers and businesses they’re supporting, I’ve found that it is easy to develop a disconnect between a Business person’s view of progress and an agile team’s view of progress.

Given the question “are we on track?” delivery teams tend to answer this on a shorter time horizon then the business tends to care about.  It’s obvious that you’ll be getting two weeks worth of work in two weeks, but what does that move us towards overall?  Will I be able to move to a new market?  Will I attract new customers?  Establish new partnerships?  That thought led me to pose this question.

We would be far better off answering these questions from the perspective of the business owner, which I think is better phrased like this.

Based on our stated business goals (hopefully outlined in a roadmap) how far are we (in terms of man days, story points, etc.) from each stage today?

Even saying something like “we believe we have 6 sprints left before reaching that milestone” could be an unhelpful answer.  It all depends on what that stakeholder is looking for in terms of visibility.  You should be prepared to answer questions like these at a moment’s notice:

  • Will we be able to make our current milestone given our current progress?  If not, what can be done?
  • Will we need more personnel given the scope of the next major milestone?  If so, how many?  When should they be brought on?
  • Are the dates for our next milestone realistic?  If not, what can be done?
Answer questions like these and you’ve gone a long way towards closing the gap between the Executive’s view of progress and the team’s view of progress.
Are there any other big questions you have found to be really impactful in helping to sync the Executive and delivery teams?  How does your team deal with this issue now?
Enhanced by Zemanta

Overtime as Failure

First, let me make myself clear.  This post isn’t focusing on voluntary overtime (though you should still consider the impact to your team, but that’s another post), it’s focusing on forced overtime in order to meet some deadline.  I consider this to be one of the worst kinds of failure.

Teams forced into this situation are typically faced with the worst of all possible choices.  Do we take shortcuts to get out on time and risk the quality issues that can come from that, or work long days and weekends, not have a life, and still likely introduce problems due to burnout?

It’s failure if you have to even ask this question, but let’s look at the choices anyway.

Keep Working 8 Hours

Hopefully this is the direction your management is leaning, but it comes with a cost.  In order to continue working at the same pace you must sacrifice scope or let the schedule slip.  Yes, personnel can change too, but I’m assuming that by the point you realize you need to make this decision that adding new people won’t get you to the finish line any faster.  Everyone must either accept the delay with the understanding that this is what is necessary to achieve the expected level of scope and quality, or strip out a few unfinished/untested features and move them to the next release (yes they should move to the top of your backlog).  This will let you release a working product of known quality without cutting corners.

Burn the Midnight Oil

Some people might not think this is so bad.  I think it’s one of the worst things you can do to your team.  What message are you sending when you’re forced into this situation?  To management?  To your team?  By deciding to work long hours, weekends, or even burning the midnight oil to put out the occasional fire (many of which were a direct result of those long hours and weekends) you’re sending the message to everyone involved that this is the new normal.
This sets a precedent and creates the expectation that all future situations like this will be addressed the same way.  Then the first time it doesn’t go this way (because you tried to do it the right way) you’ll catch flak about why your team is no longer dedicated to their job.  Do you really want to knowingly commit to 7-10s every few months?  Think of the children.

Evaluate Why

After you’ve made it across the finish line, you absolutely must evaluate how you got there.  How did you get into that situation to begin with?  Did the team commit to too much?  Did certain features take longer to implement or test than the team estimated?   Did the team not consider testing costs?  Were there a lot of unknown unknowns that crept in?  Maybe some other part of the process caused the schedule to drag?  You need to answer these questions in order to avoid this type of situation in the future.  

Don’t Go There

This is one of those cases where the best answer is to avoid asking the question in the first place.  Pull things that would normally be done at the end of a project earlier into the schedule.  Build your installer or deployment pipeline after the first couple weeks, produce system-level tests for each new feature you add (and make sure they pass before moving on!), do code reviews on a per-feature basis rather than monumental reviews at the end, etc.  The more frequently we do these things the better we get at them and it also has the welcome side effect of enabling us to be releasing almost all the time.
Remember, no matter what anyone tries to force you to do Quality Is Not An Option.  Be a professional and stand your ground.  This is a tough spot to be in, but burning your team out or torching the codebase with sketchy implementations will do more harm than good in the long run.
Comments are open.  I’m sure everyone has their own stories or advice to lend to this situation.  Let’s hear it!

My Personal Manifesto

I actually started this post back in August of 2010 under the title “What Values Drive Me?” but for some reason I never finished.  Perhaps this type of self-reflection would have been too much?  Either way, here is my meager attempt at explaining what drives me and the type of professional I try to be.  An instruction manual if you will.

The general format of these sections will define what type of X I strive to be.  I think the best way to discover this about myself is to flip it on its head and ask how I expect someone to deliver if I’m on the receiving end.  This will be a living post that I’ll come back and update every now and then I’ll note when I change something.

What type of professional do I want to be?

If I were paying someone else to do what I’m doing, how would I expect it to be done?

  • Take care – no shortcuts, no matter what the external pressures, even if I’m a bear about it.
  • To be kept in the loop – I’d like to be able to have a constant pulse on progress.  I expect to be able to get this feedback on demand, even if I have to bother the deliverer(s) to get it.
  • To be consulted when questions arise – I don’t want someone to get it wrong just because they didn’t ask.  Ask the question, the customer may not even have considered it.
  • To be told the truth, no matter how inconvenient – Bad news stinks, hidden bad news is worse, but it is what it is.  If you believe you’re not going to meet some date or some scope, tell the customer so they can evaluate how best to move forward.  Don’t deliberately under-promise in order to over-deliver.  It destroys your client’s ability to forecast future resources and projects.
  • To see progress not just on a chart or table, but really working – Charts are good, but they’re only part of the story.  If I can’t see some feature or functionality actually working did you really do anything?  This isn’t an unreasonable request.  Expect demos to be requested and be prepared to execute them.  Done means done, including being demonstrable.
  • If you say “done” or “complete” I expect it’s really done – “Code Complete” means nothing to me.  Is it usable?  Could I deploy it now?  Can someone who is not you pick it up and work on it?  Now?  6 months from now?  Get on the same page about what done really means, but if there is no agreed-upon definition, ask what you would expect if you were sitting where your client is.

What type of leader do I want to be?

How do I prefer to be led?
  • Lead by example, not command and control – If I expect other people to adopt practices or do things a certain way, I need to do it first and let them see the benefits.  Telling them to do it a particular way does not encourage them to understand the Why behind doing it that way.  “Just do it” isn’t encouraging, nothing can replace a good light bulb moment.
  • Expect greatness – Make sure people know they’re accountable for their work.  Encourage them to explore and grow within and beyond their skillsets.
  • Coach – make sure you can help people pick up good practices by coaching them when they need it.
  • Allow failure – failure is learning, learning is growth, just keep it in check and as short-lived as possible.
  • Encourage exploration – you don’t know everything, so let other team members discover new things to teach to you.
  • A Sense of Purpose – I need to believe in what I’m doing to stay motivated, so I want to give my team a sense of purpose to help drive them to do their best work.

What type of coach do I want to be?

If I were a team member who needed help with something, how would I expect to be coached?
  • One on one – This is really what coaching is all about.  If I’m to learn something well it should be one on one with someone who knows how to do it.
  • My hands on – If I were getting instruction I expect to be driving.  Let the other person drive when you’re teaching them and talk them through it.  Let them reason it out, don’t just do it for them or whip up an example and expect them to be able to follow what you’re doing.
  • Let others fix their issues – This is similar to the last one, but important enough to highlight on its own.  As a team lead it’s really tempting to just dive in and fix everything for everyone else.  Don’t do this, it’s a trap!  If you’re reviewing code for another team member (especially a more junior team member), don’t just go into the code and fix it for them.  Present the comments and let them go on to fix them.  They’ll grow more this way, both technically and confidence-wise, and you’ll find that in the future you’ll have less and less to fix with their work.  If you just do it for them you’ll always be doing it and you’re ruining a growth opportunity for them.  Tools providing asynchronous code reviews like Crucible work very well for this.

What type of team member do I want to be?  

What do I expect from my teammates?

  • Keep things clean – Make sure you’re following best practices as established by the team.  This means tested, documented, well-factored.
  • Keep things working –  Keep the system building and the tests passing.  If you break it, fix it right away before doing anything else.
  • Keep others updated – Make sure people know what you’re working on.  This will keep the team from duplicating work and will keep things moving forward instead of sideways.
  • Admit when you need help – We all want to prove we can solve this problem, but sometimes you just need a different perspective.  It’s OK to ask for help, remember that we’re working as a team and not as a bunch of individuals on disparate parts of the same system. 
  • Step up, but don’t overdo it – Don’t burn yourself out and don’t work a ton of hours that your team isn’t working.  You’re worth more well rested, and working 12 hour days skews what the rest of the team appears to be delivering on.  If you work a bunch of extra hours and then stop, the team’s velocity will decline and your customer/client will wonder why delivery has slowed.  Normal means normal, don’t force the rest of your team to define normal as 10-12 hour days.

How am I best managed?

  • Expect me to keep you apprised of progress somehow.  Forcing me to provide this keeps it in my face and makes me ask whether or not what I’m working on is on track.
  • Tell me what that progress report should contain.  I’m a big fan of task boards and burndown charts since you can get as much or as little information as you want, but if there is some measure or detail of progress you need that I’m not providing then tell me.  I’ll figure out how to get it to you, but I can’t know you need it unless you tell me.
  • Get me access to the people I need to get questions answered, when they arise.  I don’t like making assumptions and I try to catch myself making them whenever I can, but I can’t remove assumptions unless I can get questions answered.  I don’t like stacking assumptions or questions up to ask at a weekly or monthly meeting with the customer/client since by then I’ve likely stacked other things in the system over top that assumption, so having access to them sooner (ideally immediately) is always better.
  • Give me leeway to explore new options.  I don’t want my relevancy or my ability to deliver quality to my clients to stagnate, so I don’t want my toolset to stagnate either.  Just because an organization has historically used one tool for some purpose for so long doesn’t mean that it applies equally well to all situations.
  • Keep me challenged.  I get bored, and when I get bored I start looking for other opportunities.  I don’t like to be idle with my career, my client’s money, or my organization’s resources.  If I’m not growing I’m wasting time.

Why "User Stories" Failed Us

NOTE: Please read this entire post, I don’t aspire to become the Winston Royce of User Stories. :)

About 7 or 8 months ago our teams decided to try using User Stories as our primary mechanism for capturing requirements.  Since then, we have taken our lessons learned and have moved away from them.  The reason for their “failure” is laughable really: people couldn’t get past the name.  There were team members and customers that just couldn’t get beyond the fact that they’re called “User Stories”.  People would make cracks about Epics and ask whether it’s more like Odyssey or Gilgamesh.  In the beginning this was funny, and we had a laugh, but some people just couldn’t get past it, and we have since decided to phase out the use of that term.

The levels of success with User Stories in our group vary greatly, but as with any two projects you can’t really compare them based on a single part of their process.  The team I am supporting has delivered value consistently since the project started and we have done so not because we used User Stories (we did, and to great effect I might add) but because we were (and are) disciplined.  Other teams call functionality “done” without having high level tests against it that can be easily repeated.  I blame myself for those failings if for no other reason than I should have noticed the signs.  Someone has to, right?

On my current team when one of us starts to get lazy the other half of the pair straightens them out and makes sure that everything they thought to test has been tested, and that it’s in the appropriate place for our automation infrastructure to get at it.  We commit a change and within an hour we’ve validated (yes, that’s validated, not just verified) that latest version against all our user stories to date, against all supported configurations, including protecting ourselves from regression.  We are able to answer the question “when will version X be done?” using real-time data because we keep Jira up to date and because we understand what “done” means.  We don’t fool ourselves into thinking we can do more work in 3 weeks than we’ve historically proven we can do, and we don’t let management pressure us into committing as such.  We’ve learned to how to adjust our sprint caps for personnel fluctuation as team members are temporarily stripped away to work on other things, which happens quite often.

Like I said, it’s not the tool’s fault.  It’s unfortunate that something so trivial could kill its use in our process.  Now we work on “Features”…that contain shorts blurbs about something succinct that the system should do…and are estimated using points…  Sound familiar?  User Stories are no more or less valuable as an artifact than “shall” statements in more traditional requirements management methodologies, but they’re tight, to the point, and no one fools themselves into thinking they can craft the perfect sequence of words to build the perfect statement.  No one even tries.  Instead, the focus becomes the user’s intent, not the words in the requirements document.  And intent is best captured with higher bandwidth forms of communication, like getting everyone in the same room and talking it out.  That, I’ve learned, is the true power of User Stories; even if they’re called Features.

Agile Design: Ask, is it still valuable?

Today I got some feedback from my lead on an early draft HLD document. Being new to the team, I asked whether or not they intended to keep the overall UML static class diagram which there was a placeholder for. He said that he wanted to keep it. I agreed because it could be a good first exposure for someone trying to ramp up on how the system works. What we disagreed on was how and when that diagram is created.

I explained that I have no issue with the diagram as long as it is generated from the code, as opposed to it being created before any code is written. He responded with “up-front design is a software engineering best practice”. Right away I could see this was a philosophical difference. I responded that while I agree in principle, I have never seen an end system look like the UML diagram that came before it. There’s nothing wrong with that, the team just learns more about the system as it’s implemented and takes action to improve the design. They let it evolve. We can spend all day diagramming, but I’d rather not spend time documenting and diagramming details that have a high probability of not reflecting reality when it’s all said and done. It just makes the document misleading, and what’s more, we’ll end up having to reverse-engineer the diagrams from source to sync them up anyway.

In his defense, I’m sure he’s not really talking about the same big design up front that agilists abhor, but I still believe that up-front design all the way down to the static class diagram level is silly. If it’s a thought-exercise, fine, it’s usually helpful to at least identify your high level components in order to develop your metaphor, but don’t begin the process with the expectation that it will reflect the final system. You’ll be disappointed.

Is all design analysis wasteful? Heck. No. My stance would have been different if there were a lot of unknowns with technology or various functional behavior. The additional analysis can be used to further mitigate the risk of a costly failed implementation. Most of all, it allows the team to learn more before diving in.  However, even in this scenario I would recommended a different approach, such as Spiking the feature or developing some examples to drive TDD. I prefer an approach that provides real feedback that I’m on the right track. Diagrams aren’t very good at this.

If the team is learning more about the system, that’s the value in performing some up front design, but only when the time isn’t spent on something they would have easily discovered on their own if they had just gone ahead. When faced with a choice of more up-front design analysis, ask yourself, “Is this still valuable?” If your team will gain something from it then go for it without remorse (there’s nothing un-agile about being responsible), but once mostly everyone is comfortable, move on and get to the real (and fun) work.


Copyright © 2017 Life, Teams, and Software Engineering

Theme by Anders NorenUp ↑