Monday, 7 April 2014

Define Done

Often when I read blog posts or articles about agile, they are talking about advanced concepts or solving funky problems that happen when you're in the depths of running an agile team.

The alternative are Masters of whatever flavour of agile is in at the moment. They are saying you start by following these exact rules that will save your whole team. I call bullshit on all of them.

In a previous post, I spoke about how there is no point is applying an agile band-aid if you don't work out where you are first and then add rigour to your current processes.

Once you do work out what practices your team is using and identify them and apply rigour, it is time to start putting in place some entry and exit criteria to initiate work and define success. I consider it drawing two lines in the sand that represent where we start and where we finish.

I always start with multiple Definitions of Done that apply to sprint tasks/stories, the entire sprint/iteration and the project.

This gives the whole team an idea of what it means to have completed a task and signed it off. That doesn't mean you comply with full continuous deployment and produce production releases at the end of each sprint (although we all dream of such a utopia) but it does mean that you have an end state that is achievable and universally understood. Working software is of course, part of this end goal.

It is important that this is understood before you even start the project so get this in place and get buy-in before you seriously put in any delivery effort.

Definition of Done for a User Story
I often treat the definition of done for a user story as the exit criteria for the swim lanes on a Kanban board. This defines when a user story that fits in a sprint is considered complete:

  • Business analysis is complete [Owner: Business Analyst][Swim lane: In Analysis];
  • Technical analysis is complete [Owner: Technical Lead][Swim lane: Ready for Dev];
  • Estimation of effort [Owner: Entire delivery team][Swim lane: Ready for Dev];
  • Implementation of the user story is complete [Owner: Developer][Swim lane: In Dev];
  • Implementation of unit and integration tests [Owner: Developer][Swim lane: In Dev];
  • Integration with all other sprint stories [Owner: Developer via Continuous Integration][Swim lane: In Dev];
  • Automated packaging [ Owner: Developer][Swim lane: In Dev];
  • Automated or manual deployment [Owner: Developer and Tester][Swim lane: Ready for Test];
  • Full functional testing in a partially integrated environment where mocks are allowed [Owner: Tester][Swim lane: In Test];
  • Sign-off of user story functionality, confirming implementation reconciles to requirements [Owner: Tester][Swim lane: Ready for Sign-Off]; and
  • Sign-off from product owner that the user story has been delivered [Owner: Product Owner][Swim lane: Signed Off]
Definition of Done for a Sprint
A sprint is considered done when:
  • Sprint planning was run and included the whole team;
  • All user stories are signed-off by business;
  • All user stories have been fully integrated with the current working software;
  • Automated test coverage meets the agreed team standard;
  • A retrospective has been run and actions owned or implemented by owners;
  • Backlog has been groomed for future sprints;
  • A deployable package has been prepared and versioned for release to an acceptance environment (that may be production); and
  • Actual versus Estimated Velocity has been compared for future planning.
Definition of Done for a Project
This is a much tougher one. It depends on the situation you are in and the environment. Often we aim for working software and successfully full requirements reconciliation. There are many other things though that make this list. It is one that must be agreed to prior to delivering the project.

The important thing about any definition of done is that you must know up front what the goal posts are defined to be and not move them. Yes, you can change the way you play the game but you still know what it means to be finished.

Don't start until you know what it means to finish.

Monday, 31 March 2014

Don't Be A Jerk

In 2006, Joel Spolsky wrote a revealing blog post about how his company FogBugz hired staff. There were a lot of great insights about having strong firing policies to match your hiring policies.

He talked about technical skill and all sorts of stuff but the one thing that stuck with me was one line that reinforced my view of the world and myself: " Even before we started the company, we realized that we should add a third rule: 'Not a jerk.' "

I have worked with thousands of people now as a contractor, consultant and researcher.

Through the years, I have seen people who I would quite willingly call genius. Brilliant beyond what us mere mortals can call smart. Above the intellect of the most intellectual intellectuals. I am not one of them. They are often so aloft when it comes to perception that the rest of us look like ants on the dirt.

The thing is that I have also worked with very smart people. Not someone to be tagged with genius but very smart. Architects. ThoughtWorkers. Just smart people.

Over and over again, I have come to one conclusion when I build teams. I don't want to work with jerks. No matter how smart you are. No matter your skills or your gansta gains, there is nothing that would make me pick a pretty good team player with above average skills over genius who solved everything.

The way I see it, if I have to be stuck on a desert island with you forever building a hut or a raft or cooking the same old fish and bark we have eaten for months then I want to like you.

We are but people. We want to want to be at work if we must. If there are 40 hours of our 112 waking moments then I want to volunteer to be there with others.

Nice people make that possible.

What Joel was saying in his vast wisdom is that you have to choose good people but they have to be good people. I'd forgo your brilliance for someone who can gel with the group. I'd give up that insight for someone who was above good but liked people. And if you don't get that then you shouldn't come work with me.

Mean people are blockers.

Hire good people who get shit done and aren't jerks.

Sunday, 23 March 2014

Forget Being Lean Until You Get Some Rigour

Over and over again, people talk about Lean like it is a giant waterproof, super-fast healing Band-Aid that will fix every delivery team. They say "Toyota this" and "Motorola that" and "you're not lean enough."

The problem I have with this is when the Band-Aid is being applied to a delivery team that has no structure at all. You can't make a cowboy team leaner or even more agile without putting structure in place and then improving it.

I don't mean picking Scrum or Kanban and saying do this and then become leaner. Instead, I mean that teams must become aware of their as-is way of functioning. Identify practices and articulate them. There always are practices in place but people are not always conscious of them. Without consciousness, there is no method. Once you have method, you can use it rigourously.

Become aware of what you do now. Decide on where you want to be. Map a course of action from one to the other and most importantly, give yourself time and give yourself permission to fail and correct.

Telling a team with no self-awareness to become leaner is pointless. First find the point.

Agile - Is it only mostly dead?

One of the fathers of the Agile Manifesto, Dave Thomas (@pragdave) wrote a blog post a couple of weeks ago proclaiming that "Agile Is Dead (Long Live Agility)."

The post has been moving through the software dev community and causing much head nodding. Everyone seems to agree that the word "agile" means very little these days and has been corrupted by the trainers who will make you a Master from a two day training course for thousands of dollars.

At ThoughtWorks, we would mostly snigger at people who called themselves Scrum Masters but not because they were so quickly empowered. It was more because they missed the point of being agile and instead adopted prescriptive processes and accompanying costly tools to achieve what can be done with much less and achieve much more.

The reason that I am happy Prag Dave spoke out and voiced this is because people will hear it now.

Being agile is a way of thinking and acting and not a set of hard and fast rules that make better software. Tools and processes won't save a team. Pragmatism, rigour and constant feedback with change will.

I don't know if the word "agile" is dead. The good thing is that a lot of us agree that we need to be more agile and not do agile.

So go do that already.

Monday, 30 December 2013

Stop writing your own frameworks

I am in Darwin for Christmas. This is where I grew up, went to University and came back to work for a very short time in 2010 while trying to work out whether I wanted to stay and face the challenges of my profession.

It was very a short stay because this place is like many small Australian cities - there is a need for IT but it is satisfied by a small pond populated by a lot of medium-sized fish acting like sharks. After a very short time, that gets old.

My career is about focussing on building software that people want to use, not flexing my under-developed biceps and splashing wildly in a muddy pond. So while I was here, I did my best to learn something from the situation and not cause too many ripples. Yeah, me... the ripple maker.

As I walked in to different clients, developers on the client-sites kept asking me what frameworks I had brought with me. At first, I smiled and said .NET but then I realised they meant bespoke frameworks that I had created. They wanted to know what I carried in a swag on my portable hard drive that helped me build systems. In their case, this was for small systems of simple client-sever apps. And every dev had their own framework.

You're probably wondering what I mean by a small system. In the context of software, it is a system that services a small number of concurrent users and does not require capabilities like scalability and robustness under load. Yes, yes, you may argue all systems do but for more affordable systems with simple requirements that change infrequently, this can seem like over-kill. The developers who build these know that they are coding write-once applications. So the bits they do find themselves repeating on the next project, they build reusable frameworks for. These frameworks can then be used over and over again as they build the same designs over and over again. Reuse. Good, right? University told us reuse is good.

This is not that different to what I have seen in a lot of medium to large organisations though. It seems more common in groups that build small systems but it does cross all worlds and all demands. The difference is that the big places don't ask for my custom framework. They instead tell me about theirs.

The Problem With Your Custom Framework

Every time you build software, you should regress to the point of origin: The Requirements.

Every piece of software you implement. Every line of code you write. Every ounce of effort you exert in making the machine grind should be traced back to a requirement that a user needs in order to achieve their goal while using the software.

If you've worked with me then you still have my voice in your head droning on about the importance of requirements traceability. For the rest, expect a blog post in the very near future.

Custom frameworks are not an exception to this rule. In fact, they are the one part of any system that should be justified to kingdom come. If you can't find a business reason to build it then don't. I have very few to no exceptions to this rule.

Now, the reason this is important is because software has to be maintained. It must be extensible, robust, reusable, testable and above all else relevant. The software should never be held back by the tools and materials used to build it. They are not important. The end-user software is.

If the requirement of your job is to build software that other software uses to satisfies its requirements then framework away. If not, then you will spend a lot of upfront effort and infinite future work maintaining your framework just to keep it relevant to the systems it consumes.

People like Microsoft have many teams of many elite developers building many generic frameworks for you to build your castles upon. Unlike the sand that yours will be built of, theirs are backwards compatible, constantly updated and relevant. All you have to do is recompile or re-consume their changes and keep focussing on your business needs. You focussing on supporting multiple systems and stalling natural evolution and progression is more detrimental than helpful.

In most cases, there are two reasons developers insist on building their own frameworks. The first is that they took what they were told at university about reusability to mean that they must reuse code or they have failed. The truth is that design patterns are more reusable than code in a lot of circumstances. If you do need code reuse for one system, it will not often translate to another system unless great care is taken in the first place to design it that way and the agreement to maintain it is consciously agreed to by all parties including business.

The second reason is that developers like to build stuff that they can point at and say they built. I think this is sad and verging on the point of needy. As far as I am concerned, I should be able to look at a code base and have no idea at all what each developer wrote. Code is not about a developer tagging the mountain of obfuscated code that represents their prowess to others. It is about making something that can exist long after your are gone.

Let the nicest thing anyone said about you be that your code was clean, correct and easy to understand.

How To Know Your Framework Is Holding You Back

If you spend a lot of time working on your framework and not on features then your framework is not helping.

If you spend time justifying why systems dependent on your framework can't be advanced to later versions of general software (like newer version of .NET) then your framework is not helping.

If you write a new system with exactly the same design as the last system then you must ask yourself if you are solving the problem domain or complying with the saying that if all you have is a hammer then everything looks like a nail.

So You're Saying My Framework Should Be Thrown Away?!


Most frameworks are built to satisfy a need that an underlying framework (like .NET) does not yet satisfy. As soon as that general framework does, you should deprecate your compensation.

Stop wasting your time working out the best way to forge steel and instead buy it from the great steel works and then go about constructing great structures.

I'd much rather build the Empire State Building upon the shoulders of others than a half good piece of metal alloy that may or may not support a bridge tomorrow.

Wednesday, 27 November 2013

Stand-Up or Scrum Etiquette

My new role is on a team that has a scrum with almost 20 participants. At this point, it is important to obey the ethos of a scrum (or stand-up) or there is a potential to waste the time of many people.

Here is my basic Scrum Etiquette. It is good to remind people of it at the beginning of a scrum at the beginning of a new sprint or when things are out of control.

Scrum Etiquette:
  • Turn up on time. The scrum will start without you;
  • If you can not attend the scrum then give someone your update and they will go through it on your behalf;
  • Your update should consist of… 1) What I've done since the last scrum. 2) What I'll do between now and the next scrum. 3) Any blockers;
  • Your update should take about 30 seconds;
  • All other conversations should take place after the scrum in a Dev Huddle (for tech talk) or BA Huddle or Tester Huddle or specific delivery teams; and
  • Speak to the team and not just the scrum master. It's about sharing with your whole team and not just reporting your status to the boss.
Scrum Anti-Patterns (for the Scrum Master to look for when running the scrum):
  • More than one person acting as the scrum master;
  • Everyone speaking to the scrum master;
  • Long updates with too much detail;
  • Technical discussions that other team members aren't interested in;
  • People not mentioning blockers. People should explicitly state if they have no blockers; and
  • People looking uninterested.

I did google this and there weren't enough clear definitions. Every team is different and you will adjust to yours. This is a good starting point.

Go forth and scrum.

Wednesday, 13 November 2013

Your compiler is your friend

Today, I spent a small amount of time helping a developer solve a problem.

That may be how I start a lot of my posts for a while since I am working with some smart chaps who are learning to be better devs. The thing about learning to be a better developer is that you learn it from writing a helluva lot of code and from working with old grey haired devs like me.

Ok, I don't have grey hair but I do this wise Gandalf voice that really deserves some grey hair.

When I started developing, a compiler wasn't much without a linker. We spoke of lint and didn't mean the stuff left in driers. We had pet dinosaurs.

One thing that understanding the parts that come together to be the Build that we all speak of now is that we learnt to listen to what each part was telling us. No, no, I don't want you to go out and conduct some native American dreaming ceremony but I do want you to listen to your compiler warnings.

In today's adventure, I paired with a developer who was having issues adding a set of XSD schemas to a .NET schema collection. The thing is that this class was deprecated after .NET 2.0 and the reader feeding it was also of the past.

The compiler told us so.

The thing is that although many developers are warned over and over again that they are using an old API function and to use X instead, they persist. They ignore that and many other warnings. This however is the most common one I see outside of warnings about variables being initialised but not used.

Your compiler is telling you this for a reason. It isn't because it has had a slow day or it is having a grumpy moment. No, it consistently warns you that there is a better way to do things now and even suggests how you should attempt this.

So, we solved our issue today by listening to the warnings and using the latest and greatest (be it 3 years old) and all was well.

Yes, we have evolved as a profession to obey our build errors and not check in a broken build to avoid the hisses and boos of our colleagues. Now we must grow to listen to the warnings. They are not wasted cigarette lighters at a Pink Floyd concert. They are not a gasp of exclamation in a sea of squealing teenage girls at a boy band concert. They are not platform high heels at a Kylie Minogue concert. No.

To be a better developer, you will listen to the advice you get from your build, your static code analysis and your IDE refactoring suggestions. You will do it because it will make your code better and more up to date. You will do it because it will stop the bad things happening that happened to those before you. You will do it because it will stop my soul from hurting.

Be it Visual Studio or IntelliSilly, your IDE is your friend. Your compiler warns that there be dragons and you must listen.