2013-10-22 16:11:00 GMT permalink
2013-10-22 15:59:00 GMT permalink
I’m sure you didn’t mean to create this problem. It probably seemed to make a lot of sense at the time. The client was a pain, you were under pressure to deliver - producer over your shoulder, asking “is it done yet”. As for that Tech Lead, he couldn’t code review his way out of a paper bag.
A project that nobody cared about. Ship it. Move on.
And it shows. Because 2 years later we are staring at the code. Trying to fix up some problem or other. It’s hard to know where to start because, well, there’s not many comments, the commit messages are garbage and the little documentation that there is makes no sense.
I understand that you didn’t think anyone would download that app, but people have. And the client, despite what you thought, thinks this is quite a good product and would like to promote it, if only it wasn’t so buggy. So now it’s over to us.
It’s OK for you, and the rest of the team. You left. A contractor. Got fired. Who knows, but you’re not here now as a couple of us go toe-to-toe with your lack of error handling and crazy re-invention of the most common design patterns.
And you know what, I know that we could all write better code, that I don’t have the context of those meetings and planning session when it all made sense. I wasn’t there.
But next time just write a few bloody comments and maybe some documentation that doesn’t assume you know the app inside out already. And think about those of us who have to up pick your pieces…
2013-10-15 11:18:03 GMT permalink
How sizing stories (points, t-shirt sizes, days & hours) is more than just Numberwang.
For (digital) agencies who use agile techniques for managing the design and development process there are some added complexities hidden in the abstractions of the story sizing.
Depending on the nature of the development project, a typical agency team might run the gamut of disciplines, from Interaction & Visual Designers, working in Illustrator and Photoshop through to Python engineers coding in Vim and living in the command line. And each with a (subtly) different understanding of the complexities involved.
Planning poker is the technique of getting multiple people on the team to independently size user stories, whilst trying to avoid the risks of ‘anchoring’. It’s a great method for driving cross discipline understanding of those tiny assumptions that can threaten to derail a project further down the line.
Which looks something like this: Sat in a circle, post-it notes scattered across the floor and walls, someone is describing a level understanding of a particular user story — it’s pretty simple on the surface “As a user I can sign-in to the platform, so I can register to use the service”. People scribble on the post it notes, using the Fibonacci sequence to size stories based on the relative complexity involved for the UX (interaction and visual design) and technology teams. After a few seconds everyone stops writing and holds up their post-it notes. It’s near the start of the meeting so people are still getting a little warmed up, even so the variance in the numbers is quite high. Not just between disciplines but also between team members who work in the same area. This is where the interesting bit starts.
The discussion that follows is the bit I find fascinating. The cases where someone in tech misunderstands the complexity of a design challenge or someone missing the difficulty of integrating with a third-party (“it’s just an API call”) is understandable — that’s why we are doing this as a cross disciplinary group. These are easy to flush out and correct.
The real area of interest is where people explain the assumptions behind the scores they’ve given. At this point we are into the details, and it’s great for the momentum of the project. Weeks of thinking, sketching and notes come tumbling out in the conversation — no amount of ‘annotated wires’ can accomplish the benefit of someone challenging why “that’s only a 3”.
Capturing these assumptions is key — they make up the real scope and difficulty of a story. Often it’s also the risk factor that you’re gathering “I gave it a 21 because we just don’t know exactly how that’s going to work”. Whilst all forms of planning and project management are probably inherently flawed, you’re unlikely to get this level of collaboration and discussion whilst scoping out a typical waterfall build.
Agencies running agile are usually working with more constraints than a development shop. The client will probably have a fixed budget and timeline, so the only area of flexibility is scope. Whilst the aims of the project are (hopefully) going to be clearly documented and contractually agreed, these small instances of scope and the relationship between a ‘must’ and ‘could’ are the area of flex that teams are going to need deal with the reality of ‘unpacking a story’ and finding it’s more of a nightmare than a fairy tale. But that’s probably something to add to the backlog for another post…
2013-09-30 11:39:00 GMT permalink
2013-09-27 17:38:32 GMT permalink
2013-09-07 23:51:00 GMT permalink
2013-07-21 21:43:49 GMT permalink
2013-07-18 11:35:00 GMT permalink
2013-07-07 21:26:38 GMT permalink
2013-06-13 12:02:08 GMT permalink
2013-02-08 11:33:33 GMT permalink