Becoming Nimble the Agile Project Management Way

In dictionary terms, ?agile? means ?able to move quickly and easily?. In project management terms, the definition is ?project management characterized by division of tasks into short work phases called ?sprints?, with frequent reassessments and adaptation of plans?. This technique is popular in software development but is also useful when rolling out other projects.

Managing the Seven Agile Development Phases

  • Stage 1: Vision. Define the software product in terms of how it will support the company vision and strategy, and what value it will provide the user. Customer satisfaction is of paramount value including accommodating user requirement changes.
  • Stage 2: Product Roadmap. Appoint a product owner responsible for liaising with the customer, business stakeholders and the development team. Task the owner with writing a high-level product description, creating a loose time frame and estimating effort for each phase.
  • Stage 3: Release Plan. Agile always looks ahead towards the benefits that will flow. Once agreed, the Product Road-map becomes the target deadline for delivery. With Vision, Road Map and Release Plan in place the next stage is to divide the project into manageable chunks, which may be parallel or serial.
  • Stage 4: Sprint Plans. Manage each of these phases as individual ?sprints?, with emphasis on speed and meeting targets. Before the development team starts working, make sure it agrees a common goal, identifies requirements and lists the tasks it will perform.
  • Stage 5: Daily Meetings. Meet with the development team each morning for a 15-minute review. Discuss what happened yesterday, identify and celebrate progress, and find a way to resolve or work around roadblocks. The goal is to get to alpha phase quickly. Nice-to-haves can be part of subsequent upgrades.
  • Stage 6: Sprint Review. When the phase of the project is complete, facilitate a sprint review with the team to confirm this. Invite the customer, business stakeholders and development team to a presentation where you demonstrate the project/ project phase that is implemented.
  • Stage 7: Sprint Retrospective. Call the team together again (the next day if possible) for a project review to discuss lessons learned. Focus on achievements and how to do even better next time. Document and implement process changes.

The Seven Agile Development Phases ? Conclusions and Thoughts

The Agile method is an excellent way of motivating project teams, achieving goals and building result-based communities. It is however, not a static system. The product owner must conduct regular, separate reviews with the customer too.

Check our similar posts

Vendor Selection

When shopping for an IT solution for your enterprise, there are two things you should scrutinise: the product (or service) itself and its vendor. Many times, companies overlook the importance of the latter, giving the reason that “it’s only the product we need”.

Wrong.

What about after-sales technical support and training? Ok, so you have an in-house team with the required competency for that IT solution in question… not that I believe it’s reasonable basis to pass up on the expertise that the vendor can provide. How about upgrades, patches, and documentation?

Still unperturbed? Here’s one factor that you may not have started to consider – What happens to your product if the vendor goes bankrupt or gets swallowed by a merger and acquisition? Surely, you no longer believe this is far from possible, do you?

But how are you supposed to know the financial stability of each vendor or whether it is an acquisition target? Well, you can either conduct your own research or you can leave that up to us. Part of our job includes not only establishing linkages in the industry but also being in-the-know on such relevant information.

Evaluation of Business Needs

You can’t separate vendor selection from the process of choosing the desired IT tool. That’s why our vendor selection services starts by defining exactly what your business needs are.

Once we’ve pinned down your needs, we can then narrow down the list of possible IT solutions. Only then can we proceed with the main vendor selection process.

Have you ever been caught in a situation wherein you thought you knew what you wanted, only to end up realising it’s not what you were looking for after all? We’re here to make sure you don’t get caught in that kind of situation when choosing an enterprise-class IT solution.

With the TCO (total cost of ownership) of such solutions typically running up to hundreds of thousands of euros, you can’t afford to arrive at what you really want by way of trial and error.

These are the things you stand to benefit the moment we start working with you:

  • Thorough assessment of your IT needs. We’ll consult the people in your organisation who’ll be affected the most in order to obtain a clear picture of what your specific needs really are. Most IT solution purchases are made with very little consultation that, after installation, many of the end users don’t benefit at all.
  • Minimal interruption during assessment. As with all our other services, we see to it that the interruptions we make are absolutely necessary. So the moment we start with our work, you can still continue with yours.
  • Insightful suggestions of the required IT solution. You still know your business better. So even after we’ve gone through the assessment and given our recommendations, the decision as to what IT tool should be pursued will still be up to you. The difference now is, you’ll be making a decision based on expertly gathered information put forward in an insightful proposal.

Request and Evaluation of Vendor Proposals

With so many IT solutions companies mushrooming, it is becoming more difficult to keep track of them, their specialities, strengths, and weaknesses.

Companies selling best-of-breed products may be relatively easy to spot. But there are also other attributes that are equally important but not as well publicised. For instance, which companies offer better quality management philosophies? Which companies have strategic visions running parallel to yours? Which of them possess implementation capabilities that can cater to your rapidly growing IT requirements?

Vendors who answer positively to these queries need to be given the appropriate importance in the selection process. We see to it that these and other relevant attributes are factored into our scorecards and evaluation processes.

These are the things you can look forward to when you grant us the opportunity to serve you.

  • Experience is a vital item in our vendor selection criteria. Our vast knowledge of the reliable players in the industry will lead you to experienced vendors who can hit the ground running from day one and continue with the same vigour onward.
  • We can help you draw positive response for each of your Request For Proposals (RFPs) or Request For Information (RFIs). Did you expect these vendors to be enthusiastic in sending out proposals each time you asked them to? Think again. You’ll have to persuade them first of your sincerity to become a potential customer. With our help, your RFPs will make preferred vendors see “opportunity” written all over.
  • No need to go “Eany, meeny, miny, moe”. Deciding which vendors should move up in the selection process can take up a lot of time if you don’t know which criterion should be given more weight. Our scorecards are designed to collect the most relevant information and to generate results that will help you decide on these matters at a glance.

Interview, Negotiation, and Monitoring

As soon as you start getting positive response to your Request For Proposals, the interview process should be next. It’s at this point that vendors can present and highlight their strengths while we try to glean as much information of their true capabilities as well as their dedication to the project.

Some companies can provide proof-of-concepts and we may require them as part of the interview process. This will not only give us a better idea as with regards to their product’s capabilities, but also to their level of expertise on the solution in question.

  • We’ll help you set up the interview process and organise the evaluation committee. Members of the committee will typically include representatives from each department that will be affected by the new technology, which we would have already identified during our Evaluation of Business Needs.
  • Since our scorecards are designed to expedite the filtering and selection process, you may eventually be able to choose the finalists yourself. However, in the event that two or more vendors turn out evenly matched, we’ll help you identify the better company.
  • We’re very familiar with the price ranges of various IT solutions, including the effects on price of certain variables. As such, we can tell you whether a product’s price tag is justified or not.
  • Our exceptional familiarity on both the IT industry and the entire negotiation processes itself will give you the edge when it’s time for us to haggle for the best bang for the buck.
  • After the contract is awarded, we’ll even be on hand to monitor whether deliverables are handed over and milestones are achieved as promised.
How DevOps oils the Value Chain

DevOps ? a clipped compound of development and operations – is a way of working whereby software developers are in a team with project beneficiaries. A client centred approach extends the project plan to include the life cycle of the product or service, for which the software is developed.

We can then no longer speak of a software project for say Joe?s Accounting App. The software has no intrinsic value of its own. It follows that the software engineers are building an accounting app product. This is a small, crucially important distinction, because they are no longer in a silo with different business interests.

To take the analogy further, the developers are no longer contractors possibly trying to stretch out the process. They are members of Joe?s accounting company, and they are just as keen to get to market fast as Joe is to start earning income. DevOps uses this synergy to achieve the overarching business goal.

A Brief Introduction to OpsDev

You can skip this section if you already read this article. If not then you need to know that DevOps is a culture, not a working method. The three ?members? are the software developers, the beneficiaries, and a quality control mechanism. The developers break their task into smaller chunks instead of releasing the code to quality control as a single batch. As a result, the review process happens contiguously along these simplified lines.

Code QC Test ? ? ?
? Code QC Test ? ?
? ? Code QC Test ?
? ? ? Code QC Test
Colour Key Developers Quality Control Beneficiary

This is a marked improvement over the previously cumbersome method below.

Write the Code ? Test the Code ? Use the Code
? Evaluate, Schedule for Next Review ?

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

The Key Role that Application Program Interfaces Play

Application Program Interfaces, or API?s for short, are building blocks for software applications. Using proprietary software-bridges speeds this process up. A good example would be the PayPal applications that we find on so many websites today. API?s are not just for commercial sites, and they can reduce costs and improve efficiency considerably.

The following diagram courtesy of TIBCO illustrates how second-party applications integrate with PayPal architecture via an API fa?ade.

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

imgd2.jpg

The DevOps Revolution Continues ?

We close with some important insights from an interview with Jim Stoneham. He was general manager of the Yahoo Communities business unit, at the time Flickr became a part. ?Flickr was a codebase,? Jim recalls, ?that evolved to operate at high scale over 7 years – and continuing to scale while adding and refining features was no small challenge. During this transition, it was a huge advantage that there was such an integrated dev and ops team?

The ?maturity model? as engineers refer to DevOps status currently, enables developers to learn faster, and deploy upgrades ahead of their competitors. This means the client reaches and exceeds break-even sooner. DevOps lubricates the value chain so companies add value to a product faster. One reason it worked so well with Flickr, was the immense trust between Dev and Ops, and that is a lesson we should learn.

?We transformed from a team of employees to a team of owners. When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.? (Jim Stoneham)

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
Transformation to a process based organisation

Today’s global marketplace rewards nimble organisations that learn and reinvent themselves faster than their competition. Employees at all levels of these organisations see themselves as members of teams responsible for specific business processes, with performance measures tied to the success of the enterprise. As team members, they are “owners” of the process (or processes) to which they are assigned. They are responsible for both the day to day functioning of their process(s), and also for continuously seeking sustainable process improvements.

Transforming a traditionally designed “top down control” enterprise to a process-based organisation built around empowered teams actively engaged in business process re-engineering (BPR) has proven more difficult than many corporate leaders have expected. Poorly planned transformation efforts have resulted in both serious impacts to the bottom line, and even more serious damage to the organisation’s fabric of trust and confidence in leadership.

Tomislav Hernaus, in a publication titled “Generic Process Transformation Model: Transition to Process-based Organisation” has presented an overview of existing approaches to organisational transformation. From the sources reviewed, Heraus has synthesised a set of steps that collectively represent a framework for planning a successful organisational change effort. Key elements identified by Hernaus include:

Strategic Analysis:

The essential first step in any transformation effort must be development of a clear and practical vision of a future organisation that will be able to profitably compete under anticipated market conditions. That vision must be expected to flex and adjust as understanding of future market conditions change, but it must always be stated in terms that all organisational members can understand.

Identifying Core Business Processes:

With the strategic vision for the organisation in mind, the next step is to define the core business processes necessary for the future organisation to function. These processes may exist across the legacy organisation’s organisational structures.

Designing around Core Processes:

The next step is development of a schematic representation of the “end state” company, organised around the Core Business Processes defined in the previous step.

Transitional Organisational Forms/ Developing Support Systems:

In his transformation model, Hernaus recognises that information management systems designed for the legacy organisation may not be able to meet the needs of the process management teams in the new organisation. Interim management structures (that can function with currently available IT system outputs) may be required to allow IT professionals time to redesign the organisation’s information management system to be flexible enough to meet changing team needs.

Creating Awareness, Understanding, and Acceptance of the Process-based Organisation:

Starting immediately after the completion of the Strategic Analysis process described above, management must devote sufficient resources to assure that all organisation members, especially key managers, have a full understanding of how a process-based organisation functions. In addition, data based process management skills need to be provided to future process team members. It is not enough to schedule communication and training activities, and check them off the list as they are completed. It is critical that management set behavioural criteria for communication and training efforts that allow objective evaluation of the results of these efforts. Management must commit to continuing essential communication and training efforts until success criteria are achieved. During this effort, it may be determined that some members of the organisation are unlikely to ever accept the new roles they will be required to assume in a process-based organization. Replacement of these individuals should be seen as both an organisational necessity and a kindness to the employees affected.

Implementation of Process Teams:

After the completion of required training AND the completion of required IT system changes, process teams can be formally rolled out in a planned sequence. Providing new teams with part time support by qualified facilitators during the firsts weeks after start-up can pay valuable long term dividends.

Team Skill Development and Continuous Process Improvement:

Providing resources for on-going skill development and for providing timely and meaningful recognition of process team successes are two keys for success in a process-based organisation. Qualified individuals with responsibility for providing training and recognition must be clearly identified and provided with sufficient budgetary resources.

The Hernaus model for transformation to a process based organisation is both well thought out and clear. His paper provides an ample resource of references for further study.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Ready to work with Denizon?