Cloud Source Blog
In This HP Cloud Source Blog, HP Expert, Christian Verstraete will examine cloud computing challenges, discuss practical approaches to cloud computing and suggest realistic solutions.

Take a fresh look at your software development approach

Source: ITProPortalFor several months now, I’m involved in a project. The objective, do something we never did before. Loving innovation, that’s something for me, isn’t it? So, I embarked with very little description and started thinking at how we could build what we were looking for. I have to explain you that my piece is part of a larger project, an expansion of something that has been done a while ago, a new version.

 

But the piece I’m involved in is brand new. It will complement the overall development and give it a new dimension.

 

As we haven’t done this before, my approach is to get there one step at the time. Start small, experiment and then grow. Agile development methodologies lend themselves well to such approach.

Unfortunately, the wider project still builds on a traditional waterfall approach. So, I had just started identifying what I thought we should start with that I was told to deliver the design document. You can imagine my astonishment. Now, don’t worry, we got there, and I managed to combine the agile nature of what I wanted to do with the more traditional approach of the overall project. And frankly, I learned a lot along the way.

 

Agile does not mean undocumented

What I started with is writing a document in which I explained what my objectives were, what I tried to develop and why. The initial versions of this document were very untechnical. They covered the strategy, go-to market considerations, how the offering would be introduced etc. It also described at a high level how the deliverables would be structured and finally, but probably most importantly, it walked the reader through how a user would experience the system.

 

This document helped me think through all the aspects of what we were trying to do. It allowed me to peal the onion, understand the options that were available and decide what options to take and why.

 

It was important for me to make sure the readers could understand this user experience. So, I mocked-up some screens, I described steps in the process and I highlighted what made the approach unique.

 

As the versions evolved, the document grew and more technical and implementation aspects got described. Where in early versions I had highlighted modules, now I started to describe how those modules would interact. I was lucky to be able to build on already existing building blocks, so I highlighted those and described how they would call each other and in what sequence.

 

This led me to highlight data elements required, issues to be addressed (both technical and non-technical) and points we needed to remember for further iterations.

 

Finally we called this document the design document. Is it one in the traditional sense of the term? I don’t believe so. But it’s a very important document as it serves as the description of the future deliverables and while some parts are rather technical, most can be understood by both technical and non-technical people. So, it often becomes my vehicle to explain what we try to achieve.

 

We passed the design gate and are now officially in the build phase.

 

Build one step at the time

While we continue developing the idea further, we have started building the first module. Late last week, I got the honor to see the first demonstration of part of the module. And believe me it works well. We discovered we needed some more functionality to be added, so we will rework the design document and add the missing pieces.

Here again, it’s working one step at the time. We develop, we try out, we share what we have and demonstrate to all how it works. We then collect feedback and keep going. What is important is to keep the document in line with the actual developments and this is not always easy. It’s critical however as it keeps track of the evolution of the thinking and serves to describe the reasons specific decisions were taken.

 

While the team develops, the conversation continues, new ideas are generated and decisions made. It seems to work. Despite some pressure put upon us for the next gate, we have the freedom to experiment and think. Frankly, originally I was totally against those gates, but now I have to admit they force us to reach conclusions so we can have the developments ready for the gate. So, from that perspective, we are doing agile within boundaries if I may call it that way. The boundaries are the ones of the gates. It is not ideal, but we can live with it.

 

From Agile to Evergreen

The current process will get us to a first implementation. That is when we will see if our thinking, our decisions and our approach were good. Because that is the moment when the environment will be fully functional. It will be good to see how it will be used on a day to day basis.

 

But that is where the real issues will start. Because once we will know how clients actually use the system we will want to adapt and tweak it to make the user experience more intuitive. Unfortunately there are no magic rules for intuitive user interfaces, so it will be a cut and trial process. Ideally what we would want is to update the system every couple days, adding a feature here, changing one there. Through a continuous monitoring of the user’s reaction, we will be able to improve the appeal gradually. We also want to add functionality over time. Actually I have a whole list of things I’d like to do, but will only do those one at the time.

 

All this leads to a really agile approach where new releases are made available every couple days. But that implies we can test our evolutions fast enough. HP, has built experience in testing through its participation in the OpenStack testing as Monty Taylor describes in an article dated last December.

 

I’m optimistic we will get to that point. It may take some time as we improve the agility of our development methods.

 

Having the tools at our disposal.

Developing in an agile approach implies the developer can focus on improving the software continuously. This means a lot of the required tasks are automated. This is the case for testing in particular. Being able to come up with a new release every couple days requires automated testing. The tools exist, and HP have one, called Lab Management Automation.

 

You also want to make sure you go through different types of testing, so you need to set-up multiple environments and then install your application on these. Fortunately cloud allows you to provision these environments quickly, but you’re left with the installation of the latest version of your software and its associated middleware on each of these environments. Here again, this can be automated. This is what is referred to in the above article as CI, continuous integration. HP’s Continuous Deployment Automation, we use in this project, handles the deployments during testing, but also the production ones. This allows us to speed-up not just the testing, but also the

implementation of new revisions, making evergreen software possible.

 

Conclusion

Through this project I learned about agile development the hard way. But it was really interesting for me to experience how the development process is changing drastically in the new style of IT. IT consumerization has brought us to expect continuous improvement in the tools we use. The time of large and complex version migrations are over. Increasingly we will see things evolve one step at the time.

The tools are available, one of the big barriers though is the processes set-up by the enterprises. You know, we have always been doing this way, why do you want to change? So, what has been your experience? Want to share?

Labels: cloud| CloudSource
Comments
Kylie Wilson(anon) | ‎03-10-2014 12:11 PM

Hi, we use Scrum org wide for project management, and its working well compared to waterfall method. As part of company sponsored training, I also got my <a href="www.scrumstudy.com/">agile scrum certification</a> ; <a href="http://www.scrumstudy.com/scrum-master-certification.asp">Scrum Master Certification</a> recently.

Ella Mapple(anon) | ‎03-10-2014 12:15 PM

To stop making avoidable mistakes in project management one can also try attending good <a href="http://www.PMstudy.com/">PMP classes</a> conducted by any of the PMI registered REP's for gainig expertise best processes of project management. Any good <a href="http://www.PMstudy.com/">PMP prep course</a> will provide students with lots of actionable insights in project management along with preparing them for PMP certification.

حجز فنادق(anon) | ‎03-29-2014 02:41 PM

great

i love that a lot

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
Christian is responsible for building services focused on advising clients in their move to cloud, particularly from a business process and ...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation