Archive for the ‘Agile’ Category
For some years, Agile methodologies have been widely adopted within the information technology software world to bring new products and services to market quickly and efficiently, increasingly taking over from more traditional approaches such as ‘waterfall’. While it may have promised much, Agile has not been without its critics, who say that it does not live up to expectations, that users can become too bogged down in the processes and lose sight of the end goal. They also fear Agile projects become siloed into teams, rather than being visible to the organisation as a whole.
However, as an increasing number of companies are finding, Agile CAN deliver on expectations, if some simple principles are followed: what might be called “pragmatic agile”. Supporting tools also have a role, such as SCM (software configuration management). SCM can help ensure that a project remains visible to all the key stakeholders, while supporting Agile-related tactics such as Scrum.
So exactly what is Agile? First introduced in the late 90s, Agile methods are well established in the software development world as tools to accelerate time-to-market. They aim to emphasise the items on the left below, while still appreciating the value of the items on the right:
- Individuals and interaction – over processes and tools
- Working software (or product) – over comprehensive documentation
- Customer collaboration – over contract negotiation
- Responding to change – over following a plan
Taking these elements individually, let’s look at what they mean in practice.
Individuals and interactions – over processes and tools
This does not mean that there is not a place for processes and tools – of course, there has to be – but Agile is very much about people communicating with each other, ideally verbally and not just via email. A common communications element of Agile methods are daily meetings, or “stand-ups,” to review the current status of a project and to iron out issues before they escalate. In Scrum processes (see later), planning meetings provide an environment in which to understand requirements of the backlog and how to address them with collective support on the effort required. This approach helps to engender more creative thinking, because people have an environment within which they can safely suggest ideas.
So given this environment, how might tools provide support? As an example, a strong SCM system is invaluable in two ways. First, it provides visibility into how all the work fits together to deliver a working product. Second, it allows features to be developed in parallel across Scrum teams, or to move changes between sprints if work has not been completed as expected.
Working software (or product) – over comprehensive documentation
Whatever the project – whether in mainstream IT, games development or embedded software design – all too often, projects can become unwieldy, with the temptation to ‘over engineer’ and lose sight of the original goal and deadlines. Agile encourages teams to maintain focus on the outcome. This can mean delivering a working version of the software that may not have 100 percent of the features originally planned, but the product still has usable functionality. A central tenet of Agile is to take an iterative approach: it is more effective to deliver a product early and then continue to improve, rather than delay time to market.
One common Agile method is Scrum. Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Here’s a quick overview of the Scrum framework from the Scrum Alliance:
A Product Owner creates a prioritised wish list called a product backlog. The Product Owner is a proxy for the customer when determining features and priorities.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
Along the way, the Scrum Master keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
Customer collaboration over contract negotiation
In this context, customers can be internal colleagues, not just external. In any design process, there is always a danger that once a brief is agreed, the team then goes away and develops the prototype, only to find that it no longer meets the requirements of the ‘customer’. An Agile approach includes regular communication with the customer, to get his or her ‘buy-in’, so that once the product is developed, they know what to expect and have been involved throughout the development process. This can mean working with non-technical colleagues, perhaps in the product marketing department, on a level not experienced before.
Responding to change – over following a plan
Of course, solid planning is usually essential, however within that framework, Agile prescribes that it is important to be able to respond to change and be flexible. After all, when a project can take months or years to deliver, it is not surprising when market or customer requirements change.
Some deadlines, like manufacturing lead times, are hard stops in the schedule. Does that mean the project can’t respond to changing requirements? Quite the opposite. It means that, until the project hits that deadline, the team has to be as Agile as possible, embracing continuous delivery principles.
Agile – how SCM helps get it right
So far so good, but Agile can – and does – go wrong. Here are three pain points that organisations typically face and how version management (or software configuration management) system can help:
Latency – while the intention may be there, in practice it is easier said than done to prevent delays. One of the biggest bottlenecks can be retrieving source files from a repository or opening in dynamic views. Continuous integration (CI) can help address this, by ensuring that the software works at all times, not just as it is being released.
Far-flung teams – this is one that Agile didn’t see coming, at least at first. The movement emphasised co-location and collaborative programming, with daily-stand up meetings and shared workspaces. However, thanks to outsourcing, the need for differently skilled teams, particularly when building hardware and software products, and high-speed connectivity, vastly distributed development is now commonplace. Again, SCM can help support this, enabling distributed teams to keep track of what has happened and what is happening, collaborate with colleagues, but carry on working on their own projects.
Varied workflows – during the development process, multiple teams will be involved working on different elements and each team may have its own workflows. For example, the process used by the software development team is likely to be different to that used by the documentation team and the hardware design team. These teams will also be working on very different asset types – source code text files, large binary files for hardware designs or documentation PDFs. The best SCM systems should be able to handle all the different content types and workflows such that all teams work the way they want to and have visibility in all parts of the project.
Agile lessons from the games industry
The game development industry hit a number of the same roadblocks, yet many have been very successful with Agile methods, not least Perforce customers. Game developers are successful with Perforce because the tool actually increases collaboration and communication: a key Agile principle. SCM – or version management – lets the entire team, no matter the discipline, store and work with their data in a common repository.
Hardware engineers can manage their huge design files, while firmware engineers can work with their driver code, and the software developers can of course participate fully. Each team can work semi-independently, yet still make their work visible and useful to the rest of the shop early on. For example, a firmware engineer can always load the latest approved hardware simulator designs for testing.
Given that the cross-functional teams may not be at the same location and may use very different schedules and workflow, it is important to build communication into the tools and processes. The SCM system should lend itself to modern task management techniques, like task branching and pull requests. These processes improve quality and build communication into the way the organisation works.
Time to market has never been a more critical element of product development than it is today. Ensuring that products fit customer demand is what makes products profitable. Agile methods, particularly Scrum, offer a chance to address both challenges. A strong SCM tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods.
The aims of agile software development are beyond reproach: prioritising rapid delivery of working software that does what the user wants. But the application of agile methodologies can leave a lot to be desired – with frequent delivery of code mistaken for progress and users calling the shots but not understanding what they want. Here are five dangers to look out for when following an agile software development methodology.
1. Two steps forward, one step back
Agile, in the case of one of its commonest forms known as Scrum, breaks down projects into iterations that deliver potentially workable software within two to four weeks. The scope of what is being delivered from iteration to iteration can vary dramatically based on feedback from users.
This flexibility is one of the strong suits of agile. The finished software product doesn’t have to be set in stone years in advance and therefore is more likely to be relevant to a business’ needs on completion.
However, being blind to certain future demands can lead to products being developed in a way that doesn’t support those iterations, says Mike Gualtieri, principal analyst with Forrester.
Gualtieri gives the example of business users who ask developers to allow customers to look up their account history during one iteration, and then in the next iteration ask developers to allow customers to combine their account history with that of family members.
Situations such as this one leave the development team frustrated at having to go back to alter previous work, according to Gualtieri, saying, “I wish you told me that before. I didn’t anticipate that when I created the database structure.”
Also, while agile is supposed to control scope creep, there are reports that the iterative design process can lead to users demanding a multitude of changes at each iteration – making it difficult for developers to deliver.
2. Users don’t know what they want
Agile methodologies are designed to produce the software the user wants, after all the stakeholders are involved in the development process from the start.
However, people are not always the best judges of what they want. As Henry Ford supposedly said about his decision to bring the automobile to the mass market: “If I had asked people what they wanted, they would have said faster horses.”
The problem with developers relying too heavily on users to tell them what they want is that users are limited by their understanding of the underlying technology, according to Forrester’s Gualtieri.
“Say there’s a mobile app. A business person can envision the way that mobile app would work but may not be aware there’s an accelerometer and GPS, and how those can be used in combination to do some fabulous things,” he says.
Of course the end product of an agile project is supposed to be the result of a meeting of minds between the developer and the business user, rather than one leading the other.
However, the resulting product is frequently not a joint effort, according to Gualtieri, but instead the result of developers letting the user make the design decisions so they can get on with the coding.
Having business users guide coders is no substitute for a developer with a deep understanding of the business domain, he says.
3. Not ready for automated testing
The rapid delivery cycles under agile make software to automate testing a necessity to keep the quality of the product and the code from slipping.
The cost of adopting automated testing and the hassle in changing ways of working to accommodate it can seem more bother than they’re worth.
But failing to introduce automated testing makes it tricky for manual testing teams to keep on top of bugs during the short delivery times for each iteration of the software – particularly as the overall code grows in size.
4. It’s hard to get buy-in
For businesses with a long history of developing software using alternative methodologies, switching to agile requires a profound change in the way everyone from software maintenance teams to management operate.
Yet people are creatures of habit and getting the maintenance team to drop their demands for a library of documentation isn’t easy.
Getting everyone involved in a project to understand how they and their colleagues can work and mitigate risk without extensive documentation to fall back on will take a long time – for example, in the case of the Wellcome Trust it took 18 months.
Time commitments can also be onerous both for developers and business users. The IT team and the rest of the business will have to be prepared to devote regular blocks of time to discussing project requirements and outcomes, which they need to fit around the daily demands of the job.
5. Agile ignores the creative nature of coding
Critics of the agile movement claim it embodies a wider problem with software development methodologies – that the focus on process ignores the creative nature of programming.
Forrester’s Gualtieri says software development is more akin to making a movie than building cars on an assembly line.
“With these processes and methodologies, people want to take software developers, say they are all created equal, and put them into a process, turn a crank and software will come out,” he says.
“But software is a one-off. It isn’t a product of an assembly line. We need to recognize the design and creativity that goes into it.”
This focus on process ignores how important design decisions are when developing software, he says.
“In software development design decisions determine everything from how long it’s going to take to develop the software, to how good the user experience will be.”
OutSystems recently released Agile Platform 7.0. The really big news in the announcement was a total overhaul of the multi-tenancy system. Another item that flew under the radar is the new Lifetime feature, which is a method of deploying applications and managing the lifecycle (without any relationship to the TV channel).
In Lifetime, you define a number of environments and which direction things get deployed out. The pre-defined environments are Development, Testing, and Production. Lifetime allows you to “tag” a particular set of revisions with a version number, and then push them to the next environment in the chain. It detects if changes have been made in an environment’s version by marking the version number with a plus (for example, 1.8+), which gives you a cue that you may need to backport changes or deploy from downstream servers with caution. This is great for the age-old issue of people patching directly on upstream servers.
Hand-in-hand with the Lifetime feature is improvements to the way you define Applications and the system for maintaining them. There are a lot of minor changes to Applications that add up to an overall improvement. For example, there is a little reason to use an Application over a Solution, but with Lifetime, the Applications get all of the versioning and single-click deployment of a package and dependencies that Solutions have, with additional awareness of things like which eSpace in the application manages users and roles.
Ideally, you make your changes in Development, and when you are ready to test, you tag them with a new version and push to Testing. Once your testing is complete, you deploy to Production. But, what if you have to hot patch in Production? Well, there are no worries. If you take the patched version from Production and deploy it to Testing or Development, it will show the versions as being in sync again. The worst-case scenario is that you have patched Production and have changes in Development to push out. Going to the Development version and doing a merge from Service Studio with the Production version to backport the patch and then deploying the merged version back to Development will mark everything as up-to-date and happy.
Agile development seems to have received more than its fair share of media attention in recent years. Yet it is still sometimes criticized for not being “robust enough for serious organizations” from time to time. Other comments suggest that it may get a project started off rapidly, but ultimately in the long term it’s more costly.
Martin Cheesbrough is CTO of financial services and energy trading software development company Digiterre. Cheesbrough maintains that the problem here may be that some organizations simply don’t understand Agile. A simple truth is that unlike other approaches, Agile doesn’t come with a weighty 300-page book of what to do, and what not to do. Instead Agile is based on a set of guiding principles that fit onto one A4 sheet.
“Problems often occur when ‘process-orientated-people’ think that delivering a project using Agile involves following an ‘Agile process’. Agile advocates a little and often approach with the development team given complete autonomy over their tasks. The feedback loop is ongoing and concise. This ensures that you stay on track and collaborate but also guarantees that the project keeps moving and remains relevant to the business. That’s the theory – and it makes perfect sense. But when putting it into practice something seems to break down. Agile isn’t about becoming a slave to process; instead it concentrates on getting the most out of the development team and playing to each person’s strengths. Smart, creative individuals that are able to break out of the process mould and embrace the Agile philosophy are fundamental to its success.”
Cheesbrough suggests that just because Agile is light on supporting paperwork that it is deemed insubstantial, lightweight and risky.
“Agile tools and techniques promote transparency and expose how the project is developing each and every day. This means that any bumps in the road can be smoothed out before they become obstructive to progress. Companies such as Flickr are demonstrating that little and often improvements negate the need to get bogged down in ongoing projects. Each day the site makes small changes that enhance the service it offers. Isn’t this the flexible IT environment that will power the businesses of tomorrow? It’s been a long time coming, but the revolution engulfing IT to make it faster and better is demanding significant changes to development. Say goodbye to prescriptive process and hello to the more free thinking future of development.”
There are numerous, comprehensive project management models in use. To deliver a quality system, it’s critical to know the risks facing your project and to use a model that reduces those risks.
Nowadays scrum is the most popular methodology used. Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self-management, communication and decision-making. The teams in the organization work together while constantly focusing on their common interests. Scrum model emphasizes communication and collaboration, functioning software and the flexibility to adopt to emerging business realities – all attributes that suffer in the rigidly ordered waterfall model.
Initial appointment of a project manager called the “scrum master.”
Definition and prioritization of tasks to be done.
Planning sessions for each task.
Daily meetings among teams.
Identification and evaluation of potential project risks and process pitfalls.
Execution of projects in brief, high-intensity, frequent work sessions.
Reviews of progress and evaluations of completed projects.
Openness to constructive criticism and ideas for improvement.
As with any form of methodology, there are always positive and negative aspects of assigning a task or project to a set workflow. The specific nature of scrum template differs from more conventional development methodologies, as the latter are only designed to take into account and foresee unpredictability of the external and development environments at the start of the enhancement cycle.
One of the key benefits of the scrum model is its flexibility and adaptiveness as work requirements change. It provides control mechanisms for the planning of a product release, and then managing variables as the project is carried out. It means that the project can be altered and modified depending on updates, and in the end manages to establish and deliver the most appropriate release, emerging from the ability to adjust work to changing expectations once the project is underway. Because the scrum process also provides much room for individual work and contribution, developers are free to devise ideas and solutions. Usually these ideas are pioneering and innovative as the team relies on the best possible formula for the completion of their work, in order to finish the project as appropriately, and as efficiently as possible. Another positive aspect of the scrum model is the Object Oriented approach to methodology, suggesting a discrete, reliable and manageable environment. The scrum model is a highly adaptive and flexible form of project management, and procedural code does not apply to scrum project management because of this
Overall, the lack of external policy and procedure is what makes scrum a useful and unprecedented approach to project management and effective workflow. It ensures work efficiency and is strongly based on the experience and reliability of the people evolved – providing not only a stronger drive and increased self-efficacy in team members, but also room for the improvement on ones work ethic and innovation. Through this process, scrum methodology may within itself develop procedural systems, although these tend to remain subjective and only reliable in similar project circumstances, involving homogenous conditions.
Of all the agile methodologies, Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.
But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.
What do you personally think, what makes this Scrum methodology so popular and so useful? Do you personally use this model in PM? Would you enumerate some weaknesses of this approach, if any?
Feel free to share your comments and on thoughts.