Category Archives: Development process

We hate Enterprise too but…..

Posted on by
Reply

13 years I’ve been dealing with large platforms in multi-countries and territories.  At the start of each project we say to ourselves how can we do it differently, how can we be more lean, more agile, more flexible, more fluid.  I’m a coder at heart, I’ve recently fallen back in love with the open source world and love hacking away in whatever spare time I have, building apps in an agile free flow manner.  It keeps me up to speed.  I can still code an application (not in the most elegant way, mind) with the best of the geeks in some hackathon in soho or some more exotic climate if I’m lucky.  This is my first instinct, just get shit done.  Don’t faff over architecture, spend money.  I hate layers of bureaucracy that develop in projects.  Why can’t we just sit down and code out functionality in a permanent beta rollout.  That’s surely the future? Its surely something we all aim to achieve? So yes I hate enterprise and everything that gets in the way to slow things down.

But and there is a massive but. I have learnt over the years that the odd software project can come off the rails.  Why? Geeks maybe? Bad management maybe?  The reality lies in the complexity of solutions as they gather momentum.  Whether that’s momentum in terms of the reach of the application such as a global platform, increased functionality, increased numbers of developers churning out code,  increased product stakeholders.  Even the very nature of the application becoming business critical with many moving parts. All of which need to be tamed, this agile constant beta development approach is great in startup mode but like a new puppy they eventually need to be tamed otherwise developments have a tendency of becoming unplanned. Resulting in unmanageable code and an unsustainable solution.  We need to organise the chaos into a controlled ecosystem and as the complexity increases, the modules and lines of code grow, all increasing the management burden which in turn, make the whole approach of getting releases out more rigid as we fight to tame the beast that we have created.

Getting the architecture right at the beginning helps with this process, but with everything, progress and ideas keep flowing all of which challenge this architecture immediately.  We adapt to keep up, but with this adapting, changes the nature or our original intentions and starts to introduce the odd little bit of chaos into the solution.  This chaos is a good thing, it challenges us, it helps progress our thinking, however it needs to be managed.

The real reason why enterprise ends up coming into play is because software development, which running into thousands of lines of code is by very nature complex.  But this is a myth its actually quite simple.  The thousands of lines of code have all been written to keep up with our new fast paced market and our insatiable demands for innovations, ideas and pace.  It’s our market place that is creating the requirement for enterprise, the more ideas we have the more structure we need to keep in place to tame the beast that we could end up creating.

And at the top of the human food chain with the ever increasing ideas is our digital marketeers who want us always to stay ahead of the game.  These beasts could reinvent our efforts every week. The problem is without enterprise thinking we have controls that naturally have to fall in place to protect the investment we have made so far.  On smaller solutions that do not require such heavy lifting at the backend, we can simply throw away and start again if it gets complicated.  This leads to consumable software solutions, which have their benefits and place.  However these are strategic decisions and must be made at the beginning.  Trying to change a large scale business critical solution with a strategic corporate investment into a consumable solution will lead to some very expensive software development cheques.

So what’s the answer.  I think the problem is not about about whether enterprise is a bad or a good thing.  Its about how we design the conveyor belt, how we ensure we can load the hopper of our product roadmap and ensure there is a common understanding of the order of releases.  Sometimes this requires patience, sometimes things have to wait for those larger releases that will benefit someone in your organisation but not necessary our new sexy urgent idea we may be trying to push out. Remember we are trying to bring some order to something that could quickly get so complex and out of control that the only thing we can do is throw it away and start again.  This is the real risk, every I.T. project is only a few scary ideas away from the scrap heap and this costs a lot more money in the long run.

The challenge for us how to we maintain our competitive advantage. A solution to this is a well thought out roadmap thinking ahead about the market, using real metrics about performance, your user base and how best to plan in functionality to keep them satisfied.  Enterprise is a game of chess, its hard to master and takes time.  Each move requires us to think well ahead and plan.  Even if that means planning in your agility. Its not a gain for short term game and requires a lot of patience.

Making our developments more efficient

Posted on by
2

Podcast available for download with this article click here.

We’ve been developing software and web solutions now since 96. Our development processes have changed throughout the last decade, however our fundamental development approach has always been waterfall and the tools and techniques we’ve been using have been driven by traditional software and project management methodologies.

In the last five years Agile has been a big catalyst for change in our industry. It promised speed, agility and flexibility and above it may hold the golden ticket to increase productivity. However the struggle still remains that Agile only works efficiently if your customer trusts you implicitly and is bought into the concept of time and materials. This always remains a challenge as project budgets remain finite and it will continue to remain a leap of faith for any customer buying a web solution or software. But we persist, we love agile and we believe it can give us the necessary productivity and efficiency gains. We just need to wrap it within a traditional fixed price process.

So this is what we are doing

All our development still remains waterfall. i.e. you have a start, you have fixed phases and then you have a delivery. Equally you have capped and managed budgets and delivery dates. Our customers know what they getting and when they are getting it. However when we dig deeper into the phases we use a mixture of true agile for development and a colloaboration driven approach to get the project into development. I’ll start with the latter to explain how we begin the journey;-

Starting the project is key and starting any project well sets the foundations for its success or not. There are a number of things that we must get right here…

1) Project control and governance

The plan and budget are the key fundamental controls in any project. The hardest thing to do is set out a framework plan for the project when you haven’t begun your requirements capture or discovery. However this is what we do first. Immediately as we begin discussions with our customer we use our project planning process to itemise the solution. What we mean by this, is that we use our plan to capture all the discussions we need to have about how the solution evolves, we capture what needs to be discussed, designed and who needs to participate. We then set targets by when these tasks need to be completed, not how long they will take. We set a target based on experience and then we go for it. This forms the basis of our design phase. There are technical design(TDs) activities or create/ux (UXs) design activities. We then document and run workshops and design sessions to hit the targets we set. The plan then goes on to form the governance of the project to ensure we don’t loose anything and we have the appropriate targets and budget controls. As we continue our design and specification process we then are able to evolve our build estimates, team size and run order. Governance goes on to cover more aspects of the project which I will discuss later but starting it right is our biggest governance step.

2) What are we delivering, what is our specification?

As I discussed above we use the plan to itemise the project. Its worth discussing itemising a project and what we actually mean. Itemisation means all the discussions about bits of the system, design, questions and answers that need to be dealt with to start to specify the solution. By itemising the project what we are doing is starting to create a framework for our requirements to come together. Each discussion can be grouped into functional and non functional requirements under our TDs or UXs items. We then start to structure our specification but this is where things have changed more recently. Our specification is a collaborative knowledge base that our partners, customers and suppliers can all jointly work on to design and specify the itemised elements of the solution. The knowledge base we use for all our projects is Atlaissions Confluence it gives us the necessary collaboration capability to build requirements, document them and database them. At the end of the phase we still sign off before we begin build. But the result is a collaborative knowledge base that supports the project and gives the customer and the team a clear view of what we are building.

Next up is the build

This is where we embrace agile. We know what we are building and we know how long we have. So we are able to define how many sprint windows we have. The first thing to set is your sprint window time. We recommend two week sprint windows, this gives ample time for the dev team to deliver something, but not too much time that we can’t monitor progress against objectives.

Once the sprint cycle length is defined we can then start to do our planning. To do this we revert to our specification(knowledge base) and look to break the user stories out. The team then plans around the user stories. This is a team approach using the agile methodology. But essentially all the team are doing is loading a hopper of work for each sprint cycle to then execute, based on skill, performance and ability. Again we turn to Atlaissions Greenhopper product to plan the sprints, load the hoppers and monitor performance against those hoppers. Greenhopper gives us the necessary repository of historical performance, burn down tools and planning boards to do this collectively and efficiently within the team. Here the Kanban approach provides the necessary collective organisation of the team and their status reporting against task.

So during the sprint cycles we can back off the plan a little and just report progress against sprint. We don’t need to worry about too much detail in your project plan, just key milestones and the sprint cycles and performance against those sprint cycles, the software does the rest.

During the project we use continues integration on our builds so we manage the build of the software and source control. We are also starting to look at automated functional testing. Here we are looking at platforms such as Teamcity and Selenium testing. We need to do more work to standardise our approach across all our technologies, however automation is key to improve quality and keep the code base together.

Another area we are also addressing is the concept of review boards for peer reviewing of checked in code on projects. This sounds bureaucratic, however it is essential to sanity check code but also to provide knowledge sharing across the whole solution. We haven’t quite got a full solution rolled out but its something we are definitely looking to apply to our next round of projects.

Testing

Often over looked and left to the last minute to plan for.  Amaze’s approach is to wrap testing into all phases of the project.  The test plan starts up at the specification phase of the project.  We focus on acceptance criteria and unit testing with the final wave of alpha and beta testing being performed by independent teams either within Amaze or externally via our partners. Again we turn to Atlaisson and the Jira platform to manage issues as they are raised and to ensure the correct fix, deploy and re test cycle is provided.  It is also key that all our projects are fully tested independently for security, cross platform/ device, performance and load testing and any compliance requirements such as QCI.

Project Governance

Finally we turn back to overall project governance and programme management again.  We mentioned it at the beginning of this article however it is the most critical function of any project. Failure to build the right set of principles into the project governance leads to projects loosing control and often overrunning.  So these are our principles..

1) The team own the solution and the project not the project manager.  The project manager must ensure joint and joined up ownership is maintained throughout on the project.

2) Start each week as if its the last.  Keep the pace up on the project and ensure we are delivering every step of the way.  There’s not time for last minute saloon on any project this is not University.

3) Budgets and hours burn are key.  Make sure we are not wasting time and we look at productivity throughout.  This includes quick decision making, collective ownership, delegation. Don’t be afraid to off load heads from your project if they are slowing down decision making or complicating things. Smaller teams can deliver much quicker.

4) The plan must be target driven not reflective.  We need to drive ownership and weekly deliverables using the plan.

5) Use the tools to report status, removing the need for reports and spreadsheets that are often not read.

6) Ensure smooth an open communication across the whole team and your customer.  There should never be surprises.

7) Deal with problems never put you head in the sand.  If somethings difficult it is most likely a problem that is not going to go away the quicker its dealt with the lesser the impact.

8) See the big picture.  Its not next weeks onsite discovery you need to just worry about, its the end game, the live project.  Don’t loose sight of what we are here to do.

So to conclude

Agile is not everything and will not fix the majority of projects out there, particularly the fixed price ones.  Its not a magic wand, however it has brought about some good tools and collaborative approaches that encourage good shared ownership in the project deliverables.  Each project should be looked at from a ownership perspective, we should look a production values and how we streamline delivery using efficient approaches to both share information and to manage how we assign tasks to the development team.  The teams themselves need to exposed to this thinking and able to contribute in the direction of the project.  Above all we need to stay results driven, very efficient and share ownership in the end game.