By Edward Campbell
This article is a summary of an executive briefing on techniques and tools for introducing AGILE approaches into your daily SDLC development practice for the non-technical reader. If you have thought about how to approach A GILE methodology in your software development shop, this article is meant for you.
Software industry experience has demonstrated that careful implementation of AGILE software development techniques will enhance productivity, lower rework and shorten deployment cycles.
There are many types of AGILE such as SCRUM, Feature Driven Development, Lean Software Development, Iterative and others.
If there is a level of trust between the project manager and business owner or the Product Owner, their cooperation enables the selection of technical implementations that save time in the development phase and solve business problems.
Create a strategy to help your team adapt AGILE to their style: discuss a team understanding the of the AGILE Manifesto by explaining each tenet, continually reinforce by visual methods and auditory ones.
AGILE helps minimize the most common development risks:
AGILE minimizes the risk of missing requirements or completing deliverable work products because AGILE requires continual involvement of the Product Owner.
AGILE eliminates poor communication risks because project stakeholders work closely and communicate more frequently during daily planning meetings. This fosters prompt solutions to misunderstandings, disagreements and disputes.
AGILE enables prompt discovery of incomplete or incorrect requirements by requiring early and frequent deliveries of working prototypes to the customer, for review and comment. Customer confidence is built by early and frequent deliveries. Team proficiency and requirements accuracy is built by frequent prototypes and Product Owner feedback
AGILE encourages cross team collaboration to employ needed skills to get tasks done without dela y.
You probably wouldn't be reading this if you did not know or hear, already, that AGILE software development is now the most popular development methodology for new IT projects.
If you are going to try AGILE development in your organization, step one is to engage all levels of management, stakeholder and technical people and ensure everyone is on board. This has to be a team commitment and a team effort. Half-hearted participants greatly decrease your your likely hood of success. Full commitment greatly increases your chances of realizing the benefits AGILE methods can bring.
That said, what is AGILE? It is based on the 4 core tenets of the AGILE Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
This is sensible and insightful advice from a group of highly accomplished and experienced software developers. Unfortunately, there are still many development shops that are practicing the venerable Software Development Life Cycle, also known as the Waterfall method. They, like you, are looking for ways to stream line their own development practice, increase their development velocity, achieve higher success rates for their deployments and become a more predictable, reliable business unit.
It is a daunting task to change the way development is done for any organization. The large changes needed to go from document and artifact centered SDLC methodology to sprint based, bring on the change, full-fledged AGILE development are certainly not for the faint of heart.
The rest of this presentation is about working out your road map to take measured steps in the direction of embracing change rather than fighting it.
The Software Development Life Cycle, also known as the Systems Development Life Cycle, " originated in the 1960s, to develop large scale functional business systems in an age of large scale business conglomerates . Information systems activities revolved around heavy data processing and number crunching routines " ( https://en.wikipedia.org/wiki/Systems_development_life_cycle ).
At a time when most software development projects ended in large cost overruns or failure and abandonment, the SDLC was a brave and thoughtful attempt to bring order and stability to chaos:
For a full-sized, and readable, version of this graphic click this link: https://upload.wikimedia.org/wikipedia/commons/b/bb/Systems_Development_Life_Cycle.jpg
By bringing process and focus to software development, it was hoped that software development would change from the need for constant heroism to something more akin to peaceful co-existence. No doubt, the SDLC made a large contribution in that effort, especially as seen by management:
Looks good doesn't it? This was the state of the art in disciplined, top down management of the chaotic software development world, in the 1960s and 70s. But technology, especially software development technology, does not stand still.
In the decades since, many newer approaches to software development were tried. Each offered some additional dimension to the SDLC prescription. Incremental improvements made some difference in success rates and outcomes, but the complexity of developing software amid constantly changing tools, techniques and evolving best practices yielded progress grudgingly.
Some of the approaches that were tried:
Rapid Application Development, also called 3rd generation languages: Introduced the first Integrated Development Environments and the paradigm shift from procedural programming to event-driven programming. Recall the advent of the MS Windows operating system. No longer did you have to make a complete business request to use a computer. An event-driven program or the Windows interface waited patiently for you to select ANY of the many actions it supported. And when that event occurred (you clicked an icon) a pre-programmed step was executed. Many languages were developed to help with this shift: Visual Basic, Delphi/Object Pascal, PowerBuilder and others. Windows desktop applications were everywhere. But it was soon discovered that, without great discipline, the programs became hugely complicated, hard to maintain and harder to upgrade. There are still Windows desktop applications today but far fewer than before. Less costly, less complex solutions are at hand.
OOA&D – Object Oriented Analysis and Design , based on the seminal work of Grady Booch and others: A scholarly overlay on Rapid Application Development that sought to provide a rigorously complete picture of SDLC analysis and design. It is chiefly responsible for creating and popularizing the Unified Modeling Language, UML, on which much of today's new application design relies. OOA&D requires a large commitment in time, resources and knowledge, and has been fully implemented mostly by large organizations. UML version 2 is now a staple of effective application and database design.
JAD, Joint Application Design , another approach favored by government and large corporations, but dogged by the assumption that, given enough time and questions, Product Owners will be able to tell you everything you need to know, up front, to build an acceptable solution.
HTML, Hyper Text Markup Language, and the Internet : Another paradigm shift brought on by the ubiquity and openness of the World Wide Web. For the first time useful applications could be made available to the whole world but without having to install the application on each computer individually. Armies of technical staff to assist with installation were no longer needed to build and deploy solutions. HTML solutions lacked interactivity and disappointed many who had become used to highly interactive desktop applications. But the advent of computer viruses, ransomware and other unpleasantness kept driving users back to the internet.
Throughout all of the technologies tried, one aspect of development persisted: Change. Change in Product Owner requirements, scope creep, competition with other web sites all pushed the ability to adapt to change to the top of the list of needed improvements in software development methodologies. Progress could not be achieved until Change could be accepted and embraced in the software development process. Enter AGILE practices.
AGILE methods have not stood still either since the declaration of the AGILE Manifesto in 2001. In addition to the 4 tenets of the AGILE Manifesto, the following 12 principles have emerged as guiding lights in pursuit of those tenets. So here they are:
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. AGILE processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
AGILE processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
By now, I hope you are wondering if and how adopting AGILE practices in your SDLC shop might be undertaken.
If you are in a development organization and hoping to harness some of the benefit of the decades of experience in software development experience, please read on. Standing at the current point of this long journey and looking forward to a brighter future, in my experience, there are basically 2 approaches to beginning your journey to AGILE: a Proof of Concept project or gradual adoption of AGILE practices on an existing project.
Let's examine how each of these approaches can work for you.
Go all in on a trial project to gain lessons learned: pilot project, team training and AGILE development.
Steps to your first AGILE project:
Get Management Commitment: You need time and resources to train your team for this project. Management must endorse your request to the community of stakeholders that they appoint a Product Owner with the authority to decide, or drive to a conclusion, any open question from the Development Team. Management must permit your Product Manager to charge his or her time to your project, as needed, just like any other team member.
Get Development Team Commitment: Decide what training, tools and practices to pursue. Take the training, install the tools. Practice some sample projects in your environment. Don't forget to practice building and delivering a working prototype, of any kind. Above all, motivate your team to give their best and show their unique talents and skills.
Tailor your SDLC Artifacts: Generate abbreviated versions of your current artifacts with an eye toward minimizing the breadth and effort necessary to produce updated copies. Since you will likely be reporting on a per Sprint basis, you need only be concerned with the incremental Backlog Items (requirements and features) that your current Sprint has assigned. If not done in step 2, pick an AGILE automation tool, buy it, practice producing tailored SDLC artifacts and Backlog Item management and become minimally proficient in it.
Define your Backlog and Sprints – Your Backlog is your current set of work product features. As working protoypes are delivered, the Product Owner can change the Backlog to include new or changed items. Backlog Items are requirements and features that your work product must demonstrate within a working program. Defining your Sprints means only choosing a Sprint duration. For your first project, 1 month is suggested but any interval that works for you and your team is good. A Sprint interval that corresponds to your reporting requirements will make your life a little easier. The Backlog of items for each Sprint is proposed and prioritized by the Product Owner and accepted or edited down to an achievable size by the Development Team. This sounds complex and difficult, but with practice it becomes easier.
Plan your first Sprint: Using the Product Owner's Backlog of features and requirements, discuss with the Development Team what can be accomplished in 1 Sprint's duration at a sustainable rate of work. Keeping in mind that the end product of the Sprint will be a demonstrable prototype that starts, stops and produces some evidence of Backlog Items satisfied.
Sprint: Begin your first Sprint. Hold your daily meetings. Track progress, planned progress and any obstacles. Review progress and obstacles with your Product Owner. Project Manager and Product Owner: press your supporting business partners to remove obstacles. Adjust the Sprint plan, as needed, with the Product Owner to deliver working software by the end of the Sprint.
Deliver and Demonstrate: At the end of the Sprint, ensure there is a window to demonstrate the working prototype with the Product Owner, Project Manager and Development Team Lead in attendance. Others are welcome by agreement.
Review, Adjust, Repeat: Review actual progress versus planned progress. Define and document the next Sprint Backlog. Adjust practices and Backlog Items to reflect current knowledge, sustainable team level of effort, experience and any missed items from the previous Sprint. Show appreciation to the team. Start the next Sprint on time and have more fun.
Optionally, you may also want to engage an experienced AGILE practitioner. Management and Development Team commitment are most important prerequisites.
Visit each of the activities in the Proof of Concept list above. Feel free to excuse your team from any except be sure to:
Get commitment for some management support. If not a dedicated Product Owner, at get an accelerated Backlog approval commitment. Get commitment from your Development team. This can be done in 1 meeting, followed by a Memorandum of Understanding.
Create exceptions to your current SDLC process to allow for iterative requirements gathering, design refinement, development and demonstration. Pick a tool to automate as much of your current artifact burden as possible. Evaluate tools that can help. Pick the one that suits your organization and situation best and modify it to fit your team.
Define your first Sprint and 1 future Sprint's duration and Backlog of Items to satisfy.
Run your first sprint. Take notes. Define Backlog Item completion criteria.
Demonstrate your updated working application.
At this point or at the end of the next Sprint you will know if this approach is working for your team, your Management and your stakeholders. If your approach is working, it is time to ask for more commitment on more of the items in the Proof Of Concept approach.
Make no mistake, this is tricky and not an easy path. Devising a software development process to embrace change, first involves imposing change on your existing culture and practice. Success is not guaranteed. Consulting an AGILE practitioner may reduce some risks. Insist that management support and Development Team support are prerequisites.
Automate, automate, automate.
Take the best, most informative, most useful artifacts from your current SDLC process, minimize them to minimize the effort to produce them and find a way to automate their production.
There are a host of software tools that can help you do this. The production of artifacts will allow you to satisfy your management and others in the organization who fear change. Whenever possible reduce ornate documents to lists: Requirements, Design Items, Development Work Items, Unit Tests, Project Schedules and User Acceptance Tests can all be lists. And all of these lists can be managed by currently available tools.
Select your AGILE design and development tools with an eye toward:
Ease of use
Data entry performance
Ability to import data (requirements, code, diagrams) from WORD, Excel, .CSV, (add your favorite file format here)
Database design in Entity Relationship diagrams
Automated Database generation in SQL script or direct database connection
UML modeling with code generation in your development language
Web service modeling with code generation in your development language
Automated production of requirements traceability matrixes in your preferred format
Automated test case production
Link to MS Project or Excel for project management purposes
Link to TFS or other Continuous Integration tool.
(your additional requirements here)
One software development and AGILE Project Management tool that possesses all of the listed features is Enterprise Architect, http://sparxsystems.com.
Microsoft's Team Foundation Server, TFS, also provide all of the functions listed above. In addition, TFS provides a central document repository via Sharepoint. TFS and Sharepoint are based on ASP.NET and exhibit characteristics of those underlying products that some development shops prefer, particularly those shops that want a purely Microsoft solution.
Other UML modelers, code generators, and frameworks are available that can provide the same set of capabilities, albeit with the additional complexity inherent in multiple tools.
I have been in many organizations that claim to develop according to AGILE Principles. Most fail the fundamental test of any AGILE development shop:
Fixed feature sets for a release and fixed deadlines for a release are incompatible with the Principles of AGILE.
In my opinion, if your management cannot embrace staged deliveries of milestone feature sets, that are released after passing user acceptance testing, then you will not be able to fully implement AGILE methodologies and reap the greatest rewards.
But you can adopt AGILE methods, make progress and, based on that progress, convince your management to back greater change, you can achieve faster times to market, fewer releases to address bugs and more sustainable development capacity.
Stakeholders’ Support is a critical factor in making your projects successful. In other words, Stakeholder support is the most important single key to guiding your projects on the success path.
Learn about your Stakeholders. Use the most effective communication method to connect with them. Understand their needs and their point of view.
Ask yourself the following good questions about your Stakeholders:
Do your they have a positive or negative impact on your project and why?
Are they active, engaged or resistant to the project?
What is the reason they resist the project?
What is type of support you need from each of them?
Does your project have a Product Owner, appointed, supported and funded by management and stakeholders?
Is your Project Manager ready and willing to lead your team. This not easy. Please see my article about Team Leadership: http://hazaramino.com
Research, evaluate and select an AGILE Project Management tool. Advocate for the use of automation to fulfill software development artifacts
Educate yourself and your team on the AGILE Manifesto and the Principles of AGILE.
Advocate for understanding that change is part of the software development and that embracing change is the path to taking back control of software development.
Listen to your developers. If you can empower them to be more effective, you will both find greater success, productivity and satisfaction.
Links to articles that I found informative