nickbennett_blog

Tag: agile

  • Agile 101….0

    Is it ten-ten or one-zero-one-zero. I have no idea. What I do know is that this game is more addictive than heroin. If you haven’t already, download it today at your own peril. The idea is very similar to Tetris. However, the difference is you are given 3 shapes at a time and you can place them anywhere. Like all good games, the simplicity makes this one a winner. So what the hell has this got to do with Agile I hear you scream. Well, it occurred to me while playing my 100th hour how there are many parallels between the game and Agile methodologies.

    When you first start playing the game you have your Tetris mindset on. You start trying to tightly fill the spaces so there are no isolated gaps. Then the next 3 shapes appear BOOM! Game over! The game is random I’m sure, but has a  knack for giving you the exact shapes that you cannot place on the board at the right time. This seemed to me to match the common waterfall approach of project delivery. Planning to the nth degree until an unforeseen blocker appears. Game over. The striving for perfection the first time is a fallacy I’ve experienced at countless companies. Let’s be honest though, it isn’t just management it’s devs too. Give a developer a Greenfield project and they will have the same visions of grandeur that will never be achievable within the given deadline.

    So how do you play 1010 then? Well, the same way you deliver Agile projects. Piece by piece delivering value as often as possible. So for the game, it is essential to clear lines as soon as you can. The game wants you to plan for the future. Relying on certain shapes to appear. Don’t! Just try to stick to the edges and always take the lines when you can. I remind myself of Judi Dench in Skyfall saying ‘take the shot’. Replacing ‘shot’ with ‘line’. Sure, you’ll have ugly gaps on your board but you’ll also have a high score at the end. Maybe this has been a corny blog post but I think the similarities are undeniable. So for all Agile practitioners out there have a play with 1010 and maybe it’ll help you hone your understanding of delivering value at every opportunity.

  • My Full English – Project Management

    My Full English – Project Management

    Personal projects can quickly become lost by the wayside. The initial momentum is difficult to maintain throughout the project cycle. That’s why it’s always good to consider how you’re going to manage the project early on. Part of this process should be to consider how you intend to keep the project active in your consciousness and how to keep delivering features.

    Approach

    From the outset, we knew we were going to run the project with an Agile methodology. So delivering key features from the project backlog quickly as part of a 2-week sprint cycle was how we intended to deliver the application.

    Tools

    In an ideal world where money isn’t a concern, I would always recommend going down the Atlassian route. Their products are second to none with seamless integration between them making the process completely pain-free. However, it is expensive. The current MFE budget erm is £0. Fundamentally, all you need is a well-organised spreadsheet that can be shared. Google docs to the rescue. We have 3 spreadsheets.

    1. MFE Features
    2. MFE Bugs
    3. MFE Sprints

    The first 2 sheets are fairly similar and contain a list of features and bugs with priorities against each. Each item has a unique number against it so it can be tracked.

    spreadsheet

    The sprints spreadsheet has a tab for each sprint. The sprint will contain a list of features/bugs for that 2-week sprint. There is also a tab to log how many story points were achieved in each sprint. Setting out 2 weeks’ worth of work is a good way of ensuring the project is moving forward. A sprint is a commitment of work that WILL be completed.

    sprint

    Version control

    My evolution through the version control system has progressed from CVS->SVN->GIT. Each one offers something over and above its predecessor. GIT has become an industry standard and tools like bitbucket make it even easy to collaborate on projects

    What next

    In the next post, we’ll look at the database design.

  • Innovation

    Innovation

    How do I innovate? Do I need to invent something new? How do I measure success?

    As a developer, I’m often looked upon to use technology to improve processes. This to a degree is innovation but you don’t necessarily need IT solutions to innovate something. You just need a good imagination.

    “Imagination is more important than knowledge. For knowledge is limited to all we now know and understand, while imagination embraces the entire world, and all there ever will be to know and understand.”
    Albert Einstein

    Often when I oversee a process it’s easy for me to offer suggested improvements mainly because I’m neutral about it. I bring an outsider’s perspective. Becoming too close to any system can lead to not seeing the wood for the trees. I’ve compiled a simple suggested list of things to do which could help define your next project. By looking at something that needs improving you can follow the list and hopefully identify how to innovate it.

    1. Issues with the current process
    Make a list of every single bugbear you have with the existing process. Anything that is causing the process to be slow or inefficient. Every small thing no matter how trivial is worth noting down. Sometimes the small things are the quickest things to fix and have a larger positive impact than you may think.

    2. Goals of the new process
    What are the ultimate measurable goals that can be used to assess the success of the new process? Some examples may be the time to process a record, the number of people required for the process and the cost to run the process. Make sure you mark down the values of the current system so have something to measure against.

    3. Forget everything you know
    If you were to start again today, how would you set up the process? Think in terms of ultimate solutions. Don’t think about any constraints, just consider a perfect world and a perfect system. Does the new system avoid the issues listed in part 1? Good, then you’re ready for step 4.

    4. Feasibility
    Carry out a feasibility study to see how much of the ultimate solution is possible. Looks at budget and time restraints. Think about the downtime of existing systems and how you can deploy the new solution.

    5. Build
    I would recommend using an Agile approach in delivering the solution. Aiming to get quick wins out there into the real world ASAP. Look at 3rd party solutions to hit the ground running. Don’t try to reinvent the wheel. By introducing these changes quickly you can get buy-in from the users.

    6. Assess
    Once you’ve completed the changes that budget and resource has allowed, take a look at your initial goals. Did you hit most of them? Yes, then it was a success. Cross-reference your ‘perfect solution’. Maybe you already have an idea about your next project may be.

    Processes, technology and requirements are always in constant flux. You should look to re-assess any system at regular intervals to see if you can make further improvements. Remember 3rd parties may be able to help in the future if they can’t at the moment.

    I hope you find this useful.