If you\u2019ve been in software development for any time at all, you\u2019ve probably gotten this question at conferences, in meetings with vendors, or even from your own team. Everyone seems to want to know if you\u2019re on board with the Agile development process.<\/p>\n
This workflow approach is now so well regarded that whole trainings are devoted not only to the overall Agile methodology, but to specific accreditation levels within the process. Yes, you too can become a Certified Scrum Master, if you\u2019re willing to follow the movement.<\/p>\n
While the devotion to Agile practices sometimes borders on religious fervor, some teams aren\u2019t actually clear on everything Agile development entails. Quite often, I\u2019ll hear developers insist that they\u2019re Agile\u2014but they\u2019ve only implemented one or two of the core practices like Standups.<\/p>\n
Before I tell you how to dive into the world of Agile, let\u2019s clarify why you would want to adopt this approach in the first place.<\/p>\nYoung beautiful woman with facial expression of surprise standing over gray background. Wearing in trendy black dress and glasses. Looking at the camera<\/figcaption><\/figure>\n
2 Who Needs Agile Development<\/h1>\n
The appeal of Agile is, at its core, a magic wand… with a designer label. By waving it over their team, managers hope that suddenly, their projects will have a silver bullet solution to product development, collaboration, and on-time product delivery.<\/p>\n
Let\u2019s be honest. In an industry where the vast majority of projects miss their initial deadline and are crawling with bugs at launch, we\u2019d all love a guaranteed solution to improve development.<\/p>\n
Most teams, large and small, are looking to Agile because their present approach is frustrating as hell.<\/strong><\/p>\n
If they\u2019re from the waterfall camp, they know how stifling the assembly-line approach can be for having a sense of the entire project or handling mounds of complexity with a deadline that\u2019s months away. Teams who aren\u2019t working with waterfall or Agile are usually working in their own personal brand of chaos, complete with unclear job responsibilities and a very disconcerting lack of direction.<\/p>\n
If you\u2019re reading this article, my guess is that you\u2019re trying to rid your team of these chronic, debilitating problems:<\/p>\n
\n
Slipping due dates<\/li>\n
Missed software requirements<\/li>\n
Clients unhappy with the finished project<\/li>\n
Requests for revisions immediately upon delivery<\/li>\n
Grumbling team members<\/li>\n
Huge backlog of \u201csomeday\u201d add-ons<\/li>\n
Version 1.0 never ships, gets folded into v. 2.0<\/li>\n
The manager never knows when the project is going to wrap up<\/li>\n<\/ul>\n
Sound familiar? While Agile can\u2019t work miracles out of thin air, it is pretty fantastic in certain circumstances.<\/p>\n
<\/h1>\n
3 Who Doesn\u2019t Like Agile?<\/h1>\n
Before you go whole-hog with adopting Agile, it\u2019s good to know that Agile practices go against the grain with certain personality types, so carefully consider your team before you sell them on a changeover.<\/p>\n
Cowboys and mavericks<\/strong>\u00a0really chafe at the idea that they have to inform others about their progress and craftsmanship every day. They\u2019d rather be out on the range, free from any distractions, until just before the deadline hits, and then commit their code all at once.<\/p>\n
Heroes and crisis managers<\/strong>\u00a0love to swoop in and save the day\u2026 but they forget that in order for them to shine, something needs to be broken. Because Agile development tries to identify and remove problems before they become crises, heroes get restless for an adrenalin rush and some recognition.<\/p>\n
Brilliant hermits<\/strong>\u00a0are coding wizards, but their people skills aren\u2019t exactly warm and fuzzy. For them, the idea of having to interact with non-programmers who don\u2019t speak their language is close to painful.<\/p>\n
<\/h1>\n
4 The Magic of Agile<\/h1>\n
Almost every other project planning philosophy depends on the idea that hyper-detailed planning will save the day. The thinking goes that if project members can just outline every single little task, put those on a calendar, and focus on their specific assignments, then everything will turn out splendidly.<\/p>\n
Don\u2019t we wish.<\/h4>\n
Agile removes that unfounded optimism and replaces it with a gritty realism that embraces and tests all of the surprises that hide within every project as it strives to bring people out of their silos into collaboration.<\/p>\n
Better decision-making<\/strong><\/p>\n
Instead of making decisions based on theoretical screens and theoretical use cases, Agile practices create simple test scenarios early and often so everyone gets a sense of what what direction the software is going. With feedback from customers and other stakeholders at regular intervals, you can finesse the project as you go.<\/p>\n
Honesty with unknowns<\/strong><\/p>\n
Creating custom software means you\u2019re swimming in a sea of unknowns every day, primarily because you\u2019re creating something entirely new. You\u2019re not following a map, you\u2019re mounting an expedition. \u2028 Agile practitioners completely accept the reality of unknowns and actually expect to discover \u201cimpossible\u201d issues they didn\u2019t anticipate. Instead of panicking and ditching the unfamiliar feature, they have tools\u2014and confidence\u2014to break down the problem and move ahead.<\/p>\n
Transparency<\/strong><\/p>\n
When developers, programmers, management, and customers service reps are checking in at every stage of the project, you avoid misunderstandings and the need for massive course corrections at the last minute. There are plenty of opportunities for clear communication.<\/p>\n
Risk management<\/strong><\/p>\n
When you decide to identify and attack risks early, there\u2019s less chance of getting blindsided by a problem you didn\u2019t anticipate. Seasoned Agile leaders and teams know how to smoke out risk and tackle it first rather than sticking to the easy, safe tasks we all tend to want to jump into.<\/p>\n
Cost savings<\/strong><\/p>\n
Budgets really take a beating when roadblocks and last-minute overhauls run up programmers\u2019 hours. Minimizing these cost vampires eases tensions on multiple levels, obviously.<\/p>\n
One of the unexpected advantages in using Agile is that customers are sometimes thrilled with a stage of software development that seems rudimentary to programmers. By avoiding an overbuilt solution with snazzy features that will never or rarely be used, you\u2019ve just lopped off precious time.<\/p>\n
Frustration reductions<\/strong><\/p>\n
Programmers hate those moments when a finished product is unveiled after months of blood, sweat, and tears, only to have the customer say, \u201cThis is great, but can you add on this feature, too?\u201d Regular interactions with customers help shape priorities earlier in the development process.<\/p>\n
Regular team updates also reduce misunderstandings about the job\u2019s parameters and confusion over responsibilities so team members don\u2019t get territorial or dwell in misinformation.<\/p>\n
Safer revisions<\/strong><\/p>\n
Because the software is built with input and transparency from several fronts, more programmers know what\u2019s happening on the inside. If a change does need to be made, it can happen without creating a cascade of problems that will take an inordinate amount of time to identify and correct.<\/p>\n
The process is also safer because, when Agile is done well, team members feel free to speak up when they see a major problem in the headlights. They also have many opportunities in the feedback process to talk about these issues.<\/p>\n
Teambuilding<\/strong><\/p>\n
We would all love a roadmap to help us avoid trouble, , so it makes sense to look for a way to combat all of these problems that we\u2019ve all created\u2014and survived\u2014at one time to another.<\/p>\n
But the biggest secret in Agile management is not the ability to hit deadlines or better match customer expectations\u2014it\u2019s the team that\u2019s created in the process. A collection of eager programmers can be transformed from talented individuals into partners who work with each others\u2019 strengths and weaknesses as they teach themselves new practices.<\/p>\n
<\/h2>\n
5 Getting Started with Agile Project Development:\u00a0 \u00a0 \u00a0Two best practices<\/h2>\n
Managers might disagree on the best methods to use with a team that\u2019s just starting out with Agile, but I think one piece of wisdom is certain: don\u2019t try to hit your team with all of the practices at once in some sort of Agile boot camp.<\/p>\n
While your programmers might be completely gung-ho for the change, truly integrating Agile into your workflow takes time. After using Agile to lead my teams for years, I highly recommend these two practices to introduce your team to this new paradigm.<\/p>\n
5.1 Agile Intro Practice #1: The Daily Stand-up (AKA Daily Scrum)<\/h2>\n
This is a very short meeting\u201415 minutes max\u2014where team members are quickly summarizing where they are, where they\u2019re going, and where they might need help that day.<\/p>\n
It helps to meet at the same time each day (usually in the morning) and make it somewhere without chairs so people don\u2019t plop down and get comfy. If issues arise that need additional attention, move the discussion out of this quick-hit meeting.<\/p>\n
Who\u2019s there?<\/strong><\/p>\n
A representative for all of the major participants and stakeholders should be present. This might include managers, customers, users, product managers, and the person who sold the project to the customer.<\/p>\n
When you get all of these people touching base\u2014quickly\u2014it\u2019s a small investment that heads off a lot of problems. When a programmer says, \u201cI\u2019m working on this feature today,\u201d and the customer says, \u201cWait\u2014I thought that was an optional feature,\u201d you may have just saved a few headaches and a lot of lost hours.<\/p>\n
In large companies, this bit of face time keeps things personal and connected. See ya, silos. In small companies, where everyone is wearing several hats, it reminds teams that everyone\u2019s in this together.<\/p>\n
Once people warm up to this meeting approach, it\u2019s astonishing to see how quickly problems are solved organically.<\/p>\n
What\u2019s the agenda?<\/strong><\/p>\n
I\u2019m happy to share my framework for Agile Stand-ups, but under one condition. You can\u2019t instigate these meetings and then go brag to your programmer friends that you\u2019re Agile. These meetings are exceptional tools, but they\u2019re just the beginning.<\/p>\n
Once everyone is assembled, go around the circle and have each person answer these questions:<\/p>\n
\n
What did you work on yesterday?<\/em><\/li>\n
What did you work on today?<\/em><\/li>\n
What are the blockers? Where are you stuck?<\/em><\/li>\n
Is anything causing you need to change your estimate for your work?<\/em><\/li>\n<\/ul>\n
As you can see, these questions hold the potential to bring a lot of issues out into the open. But it\u2019s your job to make sure that everyone feels safe enough to ask important questions.<\/p>\n
<\/h2>\n
5.2 Agile Practice #2: Plan the Project in Short Iterations (AKA Sprints)<\/h2>\n
<\/p>\n
<\/p>\n
We all know the weight of the project that stretches on for months with no end in sight. And then when the deadline finally arrives, it seems like there wasn’t enough time to get it all done.<\/p>\n
Iterations remedy this mind-numbing grind by breaking the work into shorter segments that all have a beginning, a middle, and an end. These shorter time blocks are usually 2-4 weeks in length and have a very specific outcome in mind. No, \u201cmaking progress\u201d doesn\u2019t count.<\/p>\n
The iteration always starts with a planning meeting, which includes the same people in your daily Stand-up (see above). The middle is made up of the work outlined in the planning meeting, and the end includes a working demo (yes, working!) of the software you\u2019re creating.<\/p>\n
It also helps to have a retrospective at the end of every iteration so the next one has some clear direction.<\/p>\n
<\/h2>\n
5.2.1 Sprint opening meeting: The beginning<\/h2>\n
Sit down with your team and the product owner for one essential question: \u201cWhat would you like us to do next?\u201d The answer chooses the priority that\u2019s on deck. If she doesn\u2019t answer or tries to defer, let her know that without some direction, features could be late or missing. Ask her to identify which features she does not want to be late or missing.<\/p>\n
Grab a stack of 3×5 notecards and write out all of the possible tasks associated with that priority\u2014one to a card. Using those cards, the team can work through the most critical tasks, ask questions, then get more input on the requirements and expectations of the project.<\/p>\n
Give time estimates to every task. Some will be easy to ballpark, and others will be a shot in the dark. Just give it your an educated guess and adjust as needed\u2014that\u2019s what the Agile approach is all about!<\/p>\n
Identify tasks that will probably take longer than five hours and split them up, giving each new task its own card.<\/p>\n
Bonus:<\/strong>\u00a0If your team can\u2019t agree on how much time a job will take, here are a few techniques I\u2019ve used to move the consensus from \u201cNo idea!\u201d to \u201cLet\u2019s try this.\u201d These games also help give everyone a little space if an alpha on the team keeps pushing their ideas on everyone.<\/p>\n
Blind man\u2019s bluff<\/strong>\u00a0In one glance, this is a way to see if estimates are in the same range or vastly different. Have each team member write their estimate one of the 3×5 cards and then put it on their forehead. Since everyone at the table can see the numbers and they know their own, the differences or similarities can be the start of a great discussion.<\/p>\n
Roshambo<\/strong>\u00a0This version of rock-paper-scissors has each team paper make a fist, then throw down the number of fingers that represent the hours they think their project requires on the count of three. For example, if you think the project will take two hours, pop two fingers out of your fist.<\/p>\n
<\/h2>\n
6 Set work schedule<\/h2>\n
As you map out the iteration, make sure you calculated the amount of time available from the team. Yes, there are 40 hours in a week, but don\u2019t forget that you\u2019ll need some of those hours for meetings, other projects, dental appointments, etc. Don\u2019t overextend the team.<\/p>\n
Be prepared that the project manager might hit you with the anxious question,\u201d What if you\u2019re done early? Are you going to just sit around?\u201d Reassure them that the team will just start a new iteration whenever the first one is complete\u2014as long as everything is truly in order.<\/p>\n
Before you leave the meeting, make sure you have buy-in from the entire team. A contract or a formal statement is hardly necessary, but a solid, clear commitment from the whole team is.<\/p>\n
I usually make a statement at the end of these that sounds something like this:<\/p>\n
We as a team jointly agree that it\u2019s reasonable to accomplish this [set of goals] within this [amount of time]. At the end of this time, we will demonstrate what we\u2019ve accomplished using working software that we will ask the other stakeholders to sign off on.<\/p>\n
I\u2019ve seen team members so committed to the deadline that they\u2019re willing to come in early or stay late for days. And while that\u2019s commendable, it\u2019s not sustainable. The whole point of Agile methods is to remove drama and create a smooth system for reliably producing software.<\/p>\n
<\/h2>\n
<\/h2>\n
<\/h2>\n
<\/h2>\n
<\/h2>\n
<\/h2>\n
6.1 Off to work: The middle<\/h2>\n
With priorities and tasks set, it\u2019s time to dig in.<\/p>\n
While there are Agile-y processes that you can use at this point, don\u2019t worry about that right now. Changing the beginning of the process through the new planning meeting and having real-time demos at the end (see below) will dramatically improve your ability to see into the project\u2014and have better results.<\/p>\n
Make sure you\u2019re having consistent Stand-up meetings to keep team members accountable. Having that consistent, safe place to hear from all of the stakeholders and allow important questions is essential.<\/p>\n
Some teams take longer to adapt to standups if they\u2019re only accustomed to interacting with other programmers. That\u2019s fine. These meetings are so quick that they can\u2019t really complain.<\/p>\n
<\/h3>\n
<\/h3>\n
<\/h3>\n
<\/h3>\n
<\/h3>\n
<\/h3>\n
<\/h3>\n
6.2 Make it work: The end<\/h3>\n
This is the point where the rubber hits the road. Instead of mushy deadlines announced in a contrite meeting, Agile iterations end with a real-life, hands-on demonstration of what\u2019s been created in the given time.<\/p>\n
The demo<\/strong>\u00a0Each member of the team presents the part of the software that they built, making sure that there is very specific accountability. If the feature looks stupid, then\u00a0they<\/em>\u00a0look stupid. If that happens, chances are they\u2019ll make a better effort next time.<\/p>\n
Leave time for all stakeholders to ask questions and give feedback. You never know which comment is going to lead to a big breakthrough or significant pivot, so be ready to hear them all.<\/p>\n
The wrap-up<\/strong>\u00a0After you\u2019ve collected all of the feedback, gather the team together and discuss what went right, what went wrong, and what you wish had gone more smoothly. Sort through the issues so you can take the wisdom to the next iteration.<\/p>\n
Make sure you exit this retrospective meeting with at least three actionable improvements you can make. Without a clear path, you\u2019ll just keep stumbling into the same mistakes, leaving everyone frustrated with the new process and chronic team problems.<\/p>\n
<\/h2>\n
7 Is Agile Worth It?<\/h2>\n
Clearly, I\u2019m an Agile fan.<\/h4>\n
After using Agile with several teams in different companies, I can say that it\u2019s made a huge difference in how work gets done and how the team as a whole feels after the work is done.<\/p>\n
Yes, it\u2019s fantastic to hit deadlines more often and with far fewer complications than I had when I was winging it. Teams also feel a whole lot more satisfied about their work and its significance to the company through a high-communication process like Agile. It\u2019s priceless when you give a developer the chance to see the customer actually use what they built, which rarely happens in a waterfall environment.<\/p>\n
But the outcome that keeps me coming back to Agile practices is how the team learns to depend on each other. In this supportive, collaborative environment, my employees teach each other new things. They identify, uptake and execute process improvements all on their own, without any nudging from me.<\/p>\n
In short, Agile helps create positive peer pressure that lets great people create excellent software.<\/p>\n
![\"blog-agile-vs-waterfall-00\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/blog-agile-vs-waterfall-00.png\")
<\/h1>\n![\"Agile-Set2\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/agile-set2.png\")
If you\u2019ve been in software development for any time at all, you\u2019ve probably gotten this question at conferences, in meetings with vendors, or even from your own team. Everyone seems to want to know if you\u2019re on board with the Agile development process.<\/p>\n![\"Cute](\"https:\/\/hjinterim.files.wordpress.com\/2017\/02\/fotolia_80516719_subscription_monthly_m.jpg\")
![\"Agile-vs.-Waterfall-1\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/agile-vs-waterfall-1.jpg\")
<\/h1>\n![\"ciclo_desenvolvimento_agile_2\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/ciclo_desenvolvimento_agile_2.png\")
<\/h1>\n![\"Triang-w-a\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/triang-w-a.jpg\")
<\/h2>\n![\"hands-reaching\"](\"https:\/\/hjinterim.files.wordpress.com\/2017\/03\/hands-reaching.jpg\")
<\/h2>\n![\"agile_research_page_banner\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/agile_research_page_banner1.jpg\")
<\/h2>\n![\"Scrum-Diagram-v2.0-Arrows-Full-Res-1024x768\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/scrum-diagram-v2-0-arrows-full-res-1024x768.png\")
<\/h2>\n![\"1_SffL0Y7YxWoQ1Cf9GpRVEA\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/1_sffl0y7yxwoq1cf9gprvea.png\")
<\/h2>\n![\"waterfall-vs-agile-development\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/waterfall-vs-agile-development.png\")
<\/h3>\n![\"images\"](\"https:\/\/hjinterim.files.wordpress.com\/2018\/04\/images.jpeg\")
<\/h2>\n