The Best of Agile Project Management by Jason Wesltland

The Best of Agile Project Management A selection of professional insights from the Blog archive

Since 2008 our project management professionals have been sharing knowledge, experience and learning with online readers via the Project Manager Blog. Their collective wisdom provides a wealth of how to, top tips and best practice advice, for project managers, teams and businesses. To make their writings more accessible we’ve created a series of “Best of” project management topics available free to download and share. Here is a collection of excerpts and insights from blog posts that discuss agile project management and scrum development methodologies. The principles and values of agile and scrum provide insights on successful project management and software development, collaboration and more. Enjoy!

Jason Westland CEO ProjectManager.com The 4 Values of Agile & Scrum ........................................................................................................ 3 The Benefits of the Scrum Methodology ........................................................................................ 5 The Pro’s and Con’s of Scrum ......................................................................................................... 7 An Iterative Approach to Agile Project Management .................................................................... 9 The Agile with Scrum Sprint Planning Process.............................................................................. 11 What is Agile Project Management Release Planning? ................................................................ 14 The Role of Scrum Master ............................................................................................................ 16 12 Principles of Agile Project Management.................................................................................. 19 30 Day Free Software Trial ............................................................................................................ 24

The 4 Values of Agile & Scrum Agile software development is a way of developing software that has surfaced over the past decade. It focuses on getting working software up and running above an incessant and unnecessary amount of up front planning and documentation that quickly becomes outdated. One of the more popular methodologies of agile software development is scrum. Scrum is a way that self-directed project teams can work in very short development cycles, receive immediate feedback from end users, and continually look for ways to improve the way they get things done. There has been a considerable amount of information written about agile & scrum software development. But, what are some of the underlying values that are behind agile & scrum. The following is a list of four of these values:

Individuals and Interactions over Process and Tools There are three things that are needed in any software development company to deliver their products. These three things are People, Process, and Technology. People are needed in order to get the work done. Processes must be in place in order to provide a path to follow (similar to an assembly line) for the work to be complete. Finally, Technology is what the people in the company will use to create the software that is being put together on the assembly line. In recent years process and technology have taken precedence over people. This has resulted in a â&#x20AC;&#x153;dumbing downâ&#x20AC;? of decisions that are being made because everything is relegated to the realm of process and technology. Enter Agile & Scrum. Rather than an email being sent out to 7 people, an agile team member would get up and walk out of their cube and go to another agile team member and talk to them face-to-face. ProjectManager.com ÂŠ 2013 All Rights Reserved

They would lay out the situation; provide all the nuances of what is happening and the concern about the impact that is going to have on the project. The second person may not have the immediate answer but they get with another team member, huddle up in a conference room for 30-minutes and get the problem resolved. Thatâ&#x20AC;&#x2122;s people over process or technology. The same principle applies to everyone that needs to provide input be it management, a customer or another department.

Working Software over Comprehensive Documentation A criticism sometimes leveled against agile & scrum is the apparent lack of planning and documentation that is created. However, it is really not the case as agile & scrum advocates ongoing planning, not just at the beginning of a project. Documentation creation is also ongoing in an agile & scrum environment as well. It just appears in a different form than people are used to with other methodologies. There are stories, charts, product backlogs, acceptance tests, and the biggest piece of documentation of allâ&#x20AC;Śworking software. Rather than spending so much time up front on documentation that rarely gets used, agile & scrum teams use just enough documentation to get them through each sprint and through the next release of the software.

Customer Collaboration and Contract Negotiation The underlying value and the spirit of agile & scrum development is to give the client what they want - working software that helps solve their problem. Agile & scrum encourage customer collaboration and contract negotiation. Customer involvement throughout the software building process and iterative reviews allow the customer to see where the software solution is going.

Itâ&#x20AC;&#x2122;s possible for customers to change their mind on the software functionality, if it does not meet their needs, without derailing the entire project. Software development service providers must negotiate a fair and profitable way for this collaboration to occur. The best case scenario to enable such collaboration is a time and materials based agreement, as opposed to a fixed fee agreement. Any fixed contract could ultimately lead to your company losing money as the needs of the client change over time.

Respond to Change vs. Following a Plan Embracing change rather than just blindly following a plan is a value inherent to agile & scrum. Software development teams need to be able to adapt to change rather than blindly follow a plan that was set in place months or possibly years before. Constantly inspect the current situation and adapt to your environment accordingly. Even if you have not fully embraced the agile methodology in your company you can start following the principles above. Just having a different mindset and approach to your next project will yield big results.

The Benefits of the Scrum Methodology There has been a shift towards more agile project management methodologies in recent years. This has opened up the door for more iterative releases and closed the window of time between each next major release. The following are some of the benefits of implementing a methodology such as the scrum methodology. More Frequent Releases: The scrum methodology focuses on more frequent releases with less functionality. Initially this may come across as being negative. Who would want less functionality? Well, rather than wait 4-6 months for all the functionality to be released at once, the scrum methodology enables releases to be accelerated. In most cases functionality can be released every 4-6 weeks! The ProjectManager.com ÂŠ 2013 All Rights Reserved

development cycle is actually called a Sprint, which speaks to the abbreviated nature of the scrum methodology. Focus on Feature Set, Usability, and Value to the End User: The iterative nature of the scrum methodology lends itself toward a laser sharp focus on features, usability, and value to the end user. Each release must deliver value to the end user. At a certain level, it could be viewed as a phased approach to the major releases. Rather than waiting for everything to be done all at the same time, functionality is released as it comes online. Iterative Approach Allows for Changes and Improvements: Agile project management methodologies such as the scrum methodology embrace change. The waterfall method that is so common for major releases is typically resistant to change. There are forms, meetings, approvals, and other controls put in place for the purpose of preventing change with conventional methodologies. The iterative nature of the scrum methodology looks for perpetual feedback and then adjusts the plan and feature sets accordingly. Lends itself to SaaS: The Software as a Service (SaaS) model provides end users an online service as needed via a monthly subscription. Part of the expectation around the SaaS model is that there will be ongoing changes and improvements to the software. This encourages subscribers to renew month after month. The scrum methodology makes this easy to occur. The days of waiting 4-6 months between major releases are over. People donâ&#x20AC;&#x2122;t have that type of patience and there are alternatives to having to wait that long. Even if you donâ&#x20AC;&#x2122;t adopt the scrum methodology in its entirety, there are certain principles and values you can use that will allow your projects to move along on the fast track.

The Pro’s and Con’s of Scrum PRO Flexibility: The main benefit of using scrum for software development is its flexibility. The very nature of scrum is designed to inspect and adapt. Small, bitesize chunks of functionality and development work called ‘stories’ are defined and selected to work on in short, iterative, and self-contained bursts of development. This affords an incredible amount of flexibility for a number of reasons: Feedback comes in fast and furious: At the end of each short development cycle (called a sprint) the team shows everyone what has been accomplished and is now ready for their feedback. The feedback will come back about what they like, what didn’t work quite the way they expected, and input on some other areas that may need attention based upon the changing needs of the business. This feedback is then reviewed and, if appropriate, included in the next short sprint. You Don’t Get Too Far off the Correct Path: Other development methodologies can allow months and months to pass before anything is ever at the point of being reviewed or demoed. The primary focus in the early stages of non-agile methods concentrates on documentation and lots of it. By the time functionality of the software is demoed, market conditions and business needs could have changed so drastically that the initial solution that seemed like the right thing to do is now way off the correct path. In scrum, there are really not phases in the conventional sense of software development. There is not a lot of upfront design, paperwork, and forms to be filled out never to be looked at again. Rather, it focuses on development and getting usable software to the internal or external customer. This allows the software to not get too far off the beaten path or become irrelevant as a solution. The scrum team selects what they will work on: There is a prioritized list of functionality that is assembled by the product owner on the scrum team. The team has the flexibility of choosing which areas of functionality they will work on next that will be included in the next sprint. The date of the completion of the sprint doesn’t change, however, what functionality makes it into the next release of software may change depending upon the work that was able to be accomplished.

An obvious upside of scrum is its flexibility. The amount of immediate feedback and the ability for the team to turn on a dime really makes this methodology great for many software companies. CON Flexibility: One of the drawbacks from scrum is, yes, its flexibility. The very quality that makes scrum so appealing to use is also the one area that needs to be monitored very closely from a business perspective. Here’s the scenario. The company that uses scrum sells a software application that many clients use. The sales people and project managers at a company are responsible for interfacing with these customers that purchase this software. There are constant requests that come in from these customers for enhancements and improvements. These items are prioritized by the product owner on the scrum team and included on a cumulative list of items to be worked on by the team called a product backlog. The scrum team will then pick the items that make it into the next development cycle and add these to the sprint backlog. It is this sprint backlog that includes the new features and functionality that will be included in the next release of software. The clients want to know what is going to be included in this upcoming release. You provide them with a high-level overview of the sprint backlog so they have an idea of what will be coming down the pipe. The scrum team begins working and find out that they run into technical issues with a piece of functionality that takes longer to figure out than they had planned. This means something gets bumped out of the sprint backlog and opens up a potentially uncomfortable conversation with a client depending upon how critical the functionality is in their eyes. That’s part of the challenge. It is the team that makes the final decisions on what will be included and what will not be included in the next release. At times this decision may come across as arbitrary or not rooted in what is important in the bigger picture of the application within the eyes of the customers. True, this is a problem that surfaces with most development methodologies. It just feels that due to the iterative and frequent number of releases with scrum that this conversation has to be had on a regular basis.

Does scrum work? Absolutely! It has brought peace and averted many contentious and disastrous situations using outdated methodologies. Just be aware of the fact that it has the potential for being a two edged sword and you’ll be pleased with the results.

An Iterative Approach to Agile Project Management There is an increasing shift toward an iterative approach to project management. This approach acknowledges the fact that it’s next to impossible to know everything up front. The iterative approach is designed to figure out the details along the way and then make the best decisions possible based upon the current information available.

Why is the Iterative Approach to Agile Project Management Necessary? There used to be a time when project managers would delude themselves that all of the requirements for a particular project would be known up-front so a tremendous amount of time was spent gathering requirements and compiling all kinds of design documentation. Reality then hit because there is really no way to obtain and document everything you will need to know about a project, for a number of reasons: Users Are Not Sure What they Want: It is hard for clients to articulate exactly what they want until they see it. This means a tremendous amount of time could be spent in up-front planning only to find out it’s really not what the client had in mind at all. That’s why an iterative approach to agile project management is a must. It allows “baby steps” to be taken as the client uncovers and discovers exactly what it is that they are looking for their project to accomplish. Business Needs Change: Project durations can last anywhere from a couple of weeks up to many years. During this time there are all sorts of pressures that can be exerted on a company and the projects that are currently underway. A competitor could have recently introduced a new product that is undermining your customer base or, there may be financial pressures from within your company that necessitate revising the scope of a project to make it more affordable. Perhaps resource contentions with other departments make it ProjectManager.com © 2013 All Rights Reserved

necessary to adjust the duration of the project. When discovered as a project is underway, adjustments will need to be made to the project. Technologies Change: The project could have started under the umbrella of one technology, but it soon becomes apparent that a better technology has just emerged. It is beneficial for the project to take advantage of this new technology, but this will require some adjustments while the project is already underway.

Principles of Iterative Approach to Agile Project Management Agility means that something or someone is quick, nimble, and able to respond to the present circumstances at a momentâ&#x20AC;&#x2122;s notice. It is these qualities that agile project management strives to embrace. In doing so, the following agile project management principles will help an agile project manager keep up with change as it occurs: Deliver a Working Product Early and Often: One of the only ways that you will be able to determine what a client really wants is to show them what you have. In order for you to show them what you have sooner rather than later, you must use the iterative approach to project management. Former times would have held back the goods for the client to see until near the very end of the project. This was many times met with disappointment as the results were nothing like the client had imagined up front. To prevent client disappointment, deliver small, bite-size pieces of working software or project deliverables as they become available, for client feedback. They may absolutely hate what is delivered yet at least at this point you can readjust the plan or deliverable accordingly and get the project back on track before its way too late. Test Along the Way: Another important concept of the iterative approach to agile project management is to test and fix bugs along the way. Development methods such as the Waterfall Method would have all of the development work complete before the testing group would ever lay their hands on the project. This many times led to costly rework from a bug that had snaked its way through the rest of the application. Agile project management can discover and exterminated bugs early on in the project with the understanding that a bug that is fixed as soon as it is found, is much less costly to fix than one that has infiltrated an entire system. ProjectManager.com ÂŠ 2013 All Rights Reserved

1 0

Document What You Need: Team members will rarely reference everything that has been written about a project instead referencing only what they need to get the job done. The iterative approach to agile project management will provide just enough information for that particular cycle of a project. More documentation is provided once it is needed for the next cycle of the project. It’s this approach that keeps the administrative burden to a minimum and at the same time provides team members with exactly what they need to complete the project. Break Down Silos: A final concept around the iterative approach to agile project management is that small groups of people from across disciplines are pulled together to get the job done. This prevents just one group or team of people from holding up the project, but rather allows others to work on the project concurrently. With dozens of people and countless activities to be managed across multiple locations and environments conventional project management can quickly become very challenging. With an iterative approach that focuses on accomplishing just a few small steps at a time you’ll be surprised at how much progress you can make.

The Agile with Scrum Sprint Planning Process The sprint planning process used in the agile with scrum development consists of two meetings. The first is to determine what will be done in the next sprint. The second meeting is to determine how this agreed-upon work will be done. You will end up with very powerful and long-lasting results once these two meetings have occurred and the results are combined. If you have one meeting without the other or never combine the results, chances are extraordinarily high that nothing will happen. So here we discuss how to get the most out of this two part planning process

Part I – What Will We Do? The first agile with scrum sprint planning meeting focuses on what will be done during the next sprint. The product owner is the driver and brings out a list of stories important for the upcoming sprint. ProjectManager.com © 2013 All Rights Reserved

1 1

Stories are what users want the software in development to accomplish. For example, a user needs the software to sort and filter the final set of products returned by the application or, the user needs to be able to select a product and put it in their cart for purchase. How does the product owner determine what products will make it into the next sprint? Carry-overs from the previous sprint: Typically, a handful of stories may not have been finished in the previous sprint. These are good candidates for inclusion in the current agile with scrum sprint. The product owner determines what stories are still relevant, and includes and prioritizes them accordingly. Feedback from the Users: The nature of the agile with scrum development methodology is that it responds quickly to feedback from the user. Additionally, agile methodology believes in releasing smaller sets of functionality more frequently rather than waiting on massive amounts of functionality released infrequently. This allows users to assess the newest release and say what they like or don’t like about the functionality. This feedback becomes part of the product owner’s prioritization process. A Changing Marketplace: A third area that provides stories to be included in the next release is what the marketplace is doing. Competitors may have come up with a new feature that you need to include in your software. Or, there may be an opportunity to optimize software with new functionality. Once the product owner determines the list of stories to be included, she will discuss it with the team. They will vet out each story based on their current understanding with questions, ideas, and clarifications. The team then determines whether or not to include it in the next agile with scrum sprint. They will already have an idea of how long each story will take to implement as the estimating work has been done prior to this meeting. It’s now a matter of filling up the development cart with the number of hours allocated for the next sprint. For example, it may be a two week sprint with four resources working full-time at a ProjectManager.com © 2013 All Rights Reserved

1 2

75% utilization rate, which allows for 240 hours to be applied toward these stories. The team picks those stories that add up to this number of hours. A word of caution for teams that are new to the scrum sprint planning process: be careful to not over-commit. It’s easy to be optimistic early on, but when the team realizes that they won’t be able to meet their commitment, it only leads to disappointment and frustration. It’s better to under-commit and over-deliver than the other way around. Notice the delineation of responsibility that is also occurring at this point in the agile with scrum sprint planning process. The product owner determines the prioritization of what will be worked on, whereas the development team focuses on the viability of that selection and further hones that list. You now have the first part of the agile with scrum sprint planning process; a prioritized and agreed upon list of activity that will make it into the next sprint. You’re now ready to move into the second part, which is deciding how the work will be done.

Part II – How Will We Do It? The development team now gets their hands on the list of stories that everyone has agreed to undertake for the next sprint. They begin breaking the stories down into tasks and activities and doling them out to the team. There is a give and take as ‘progressive elaboration’ occurs. Team members begin working on their tasks. However, software development falls into the realm of ‘you don’t know what you don’t know.’ Once more information is uncovered about the task it may need more hours to complete. This is discussed with the team and ultimately product owner as it may jostle some of the other high priority stories on the list. The team will get better at estimating durations over time. They may even consider using some of the alternate estimating measurements below: Number of Hours: This is the most common and easy to understand concept of estimating. The team calculates the number of hours it will take to complete the stories against the actual number of hours available. Number of Points: Points can be assigned to various tasks based upon their level of complexity. Points are then tallied up until the maximum number for the current sprint has been reached. ProjectManager.com © 2013 All Rights Reserved

1 3

Number of Tasks: Tasks can be counted if they are similar in size for the sprint. Tasks are added to the sprint until it has reached its allotted number. Determining WHAT you will do does no good unless you know HOW you will do it. Knowing HOW you will do something but being unsure of WHAT you are going to do is also not good. Both elements carry equal weight when trying to get the most work out of your team and fully utilizing the agile with scrum sprint planning process.

What is Agile Project Management Release Planning? Agile project management release planning is as its name implies: flexible. Agile project management is designed to be able to turn on a dime and pivot in real-time as needs and circumstances change. This is predicated on the fact that smaller releases executed over smaller time frames will ideally not change much. Then, as that release cycle is underway, feedback and adjustments can be made that will move into the next release. Agile project management carries with it a number of benefits, such as smaller releases providing for new functionality faster and the end-users feedback constantly incorporated into the end product. This allows it to align closer with their final expectations. Understanding what agile project management release planning requires carries some inherent risks that are not typically present in conventional software development methodologies, such as the Waterfall Method. The very flexibility that makes an agile project management plan so appealing can also be the nemesis of project managers who are used to working with more structured and formal methodologies.

1 4

Fixed Date: The fixed date approach draws a line in the sand when it comes to the date the project must be complete. There is no negotiation when it comes to the date being met, for example a project to support a trade show where a new product is being introduced The Challenge: with a fixed data approach the scope of the project may have some flexibility. The team can commit to a particular date, but they may not be able to commit to 100% of the functionality being requested to be complete. The goal should be to get as much as can possibly be done by the fixed date, and then roll whatever is left into the next development cycle. What should not be orphaned for the next development cycle, however, are large pieces of critical functionality that must be complete in order for the product to provide value. Fixed Scope: The fixed scope approach draws a line in the sand when it comes to the features and functionality that must be in the product. There is no negotiation when it comes to what is included, but there may be some flexibility around the time that the project is complete. This may be the case when there are only a handful, or one, new feature being introduced and releasing the product without that functionality would be meaningless. The Challenge: Flexibility in the timing of the project needs to remain reasonable. For example, a 6-8 week development cycle that drags on another 6-8 weeks has totally missed the mark. With agile development teams it’s understood that schedules may slip days or a week on short development cycles, but it shouldn’t be much longer than that.

Devil’s Advocate “But, I have a fixed date and a fixed scope” Welcome to one of the biggest challenges of project management - working within the triple constraint of scope, cost and time. It’s at this point that hard decisions and trade-offs will need to be made. You want to be as accommodating as you can as a project manager, but when requests become unreasonable and untenable then you need to raise your hand and say no.

1 5

The Role of Scrum Master Below are some of the functions the Scrum Master serves:

Coach One word that can be used to describe what the scrum master does is to be a coach. This can be correlated to what a sports coach does for their team. They guide, admonish, strengthen, and push their team to perform their very best. This is typically somebody who has a deep understanding, love, and appreciation for the sport and wants to share this experience with others on the team. It is similar with the scrum master. This person is typically very knowledgeable about how the scrum methodology works and is passionate about its success. This excitement is then shared with others on the team in their various roles. The goal of the scrum master as coach is to push their team to always work better together, self-organize, and increase their performance.

Peer Despite the term ‘master’ that is used in scrum master, the scrum master is not the ‘boss’ or manager of the team. This may be hard to understand for conventional project managers who have come from a hierarchical, top-down approach to managing people on their team The scrum master is not higher in rank than anyone else on the team. It is their responsibilities that give them this name and separate them from other team members. The scrum master has certain functions that they are responsible for fulfilling and this is done in their capacity as an equal peer with the rest of the team.

1 6

Scrum Expert … the Scrum Master will typically serve as the scrum expert on the team. This means they are responsible for helping the team optimize the use of scrum as the methodology they have chosen to build their software. This expert role is implemented in a number of ways. This can range from the scrum master facilitating meetings, making sure team members understand their respective roles on the team, to helping others use and understand the various scrum artifacts that are necessary to keep a team running smoothly. One thing the scrum master should be careful to stay away from and that is constantly pointing out to their team members when they are “doing scrum wrong”. This is counterproductive and does not fit into the description of what the scrum master should be doing. Rather, the scrum master should catch people doing things right, and then, in the spirit of a coach show them how things can be done better.

Remover of Obstacles This is part of the role of scrum master that is comparable to that of a project manager. They need to be able to remove obstacles and impediments out of the way of their team mates. An obstacle or impediment may be anything that slows the team down from getting their work done. This could include unnecessary approval processes, slow responsiveness from other departments, or maybe even updating outdated hardware or systems. The team should be able to count on the scrum master to clear the path ahead of them. This will allow them to focus on the work that is currently on their plate to accomplish and get it done as efficiently and effectively as possible.

Dispenser of Information Another big role that the scrum master plays is to constantly dispense information to project stakeholders about where the current sprint and ProjectManager.com © 2013 All Rights Reserved

1 7

development effort stand. This can be done via the various artifacts of scrum (i.e. backlogs to burn down charts) and just common-sense communication efforts.

Facilitator ‘Facilitate’ is a great word and sums up what a scrum master should do for their team. Facilitate means “to make easier or less difficult, help forward”. The goal of a scrum master is to make the tasks, activities, and day of each of their team members easier and less difficult. This can be done by doing each of the items above and keeping the attitude of being a peer at the forefront.

Is the Scrum Master a Dedicated Role? There is some discussion about how involved the scrum master should be when it comes to the actual development work that is underway. One school of thought is that the scrum master should be exclusively dedicated to their role described above and not get buried in the day to day pressures, deadlines, and constraints that come from actually having to do the work themselves. Others feel as if the role described above may not consume 100% of the time that is available and any leftover time can be devoted to toward development work. There are pros and cons to each approach. If a scrum master is involved in development activities they could find themselves in the critical path of a project that is underway. This means that when the going gets tough or deadlines are looming they will most likely default to getting their own work done. This is understandable based upon the pressure that is put upon their particular deliverable. But, it could also let the team suffer during a time that they especially need someone filling the role of scrum master. The upside of a scrum master filling both roles is that the company may feel as if they are getting more for their money by not having to invest in two people to fill the roles. On the other hand, a person that is a 100% dedicated scrum master focuses exclusively on the activities mentioned above. They are the person that constantly ProjectManager.com © 2013 All Rights Reserved

1 8

has the big picture in mind and is always looking around the corner for what could be in the way of the project moving forward, or what opportunities could be taken advantage of to bring the sprint to a more expeditious completion. The downside of this approach is that there may need to be more resources applied to the project from a technical perspective and may cost the company additional money. Is the scrum master some mysterious super-being that wields their mysterious power over their minions? Absolutely not! Rather, a scrum master is just one part of a highly effective team that is focused on getting the right features into each product release. The end result is a working piece of software that brings the greatest amount of satisfaction to the end user.

12 Principles of Agile Project Management There has been much written on the subject of agile software development and by extension agile project management. To go back to the source of this knowledge you can spend a little bit of time at AgileManifesto.org to get an idea of where this all started, the values this methodology holds dear, along with the 12 guiding principles the original team espoused. The 12 principles of agile project management follow along with commentary on how and why each of these principles is beneficial in the rough and tumble world of software development.

Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The competitive advantage of a customer centric focus is many times lost in the shuffle of corporate politics and bureaucracy. The first principle of agile ProjectManager.com ÂŠ 2013 All Rights Reserved

1 9

project management serves to principle reminds us that software is built to be for an end user. Created to help people do their job more efficiently and effectively or, to enable end users to perform tasks that previously were out of their reach.

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Conventional and linear software development and project management methodologies cringe at the idea of change. However, you can almost be assured that there is not one software project in existence that made it from beginning to end without changes. Agile project management methodologies and software development embrace this fact. They view it as an opportunity for the end product to end up being closer to what the client or end user wanted and thus increases its usability and satisfaction.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Previous methods of developing software would concentrate on an incredible amount of documentation up front under the guise of vetting out 100% of the requirements that were needed for a particular project. The reality is that after a couple of months what you ended up with is a whole bunch of very nice and very thick documentation but no working software to show for it. Agile project management concentrates on creating and implementing working software frequently.

Principle 4: Business people and developers must work together daily throughout the project. Business people and developers must work together daily throughout the project as such collaboration helps maintain the agility of ProjectManager.com ÂŠ 2013 All Rights Reserved

2 0

software and the ability for it to change in order to keep up with the changing marketplace. This is a foreign concept to many that have worked in software development yet not worked within the parameters of agile project management. This principle needs to be taught, learned, and reinforced because it’s not something that will come naturally to most people.

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. In other words, there’s no need to micromanage teams that is following agile project management methodologies. There’s no one that knows better what needs to be done and how it needs to be done than these self-directed teams. Allow teams to figure things out, make their own decisions, and move the project forward. An agile project manager (scrum master) is there to support and enable them to get their work done.

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Much has been lost in the art of communication due ironically, to technology. Technology allows developers and business people to make it throughout their entire day without talking to anyone, if they so choose. The use of email, instant messages, text and other forms of communication have displaced face-to-face communication. While these technologies have their place, keep in mind that there is nothing better than face-to-face communication if you really want to understand someone or be understood yourself.

Principle 7: Working software is the primary measure of progress. Simple, right? Think about all of the other measures of progress that have been used in the past. Number of open bugs, number of closed bugs, velocity of bugs ProjectManager.com © 2013 All Rights Reserved

2 1

being fixed, and hours spent on a project, hours remaining on a project, budget consumed, budget yet to go, etc. These are important measurements, but, they are really all the overhead that is necessary to get the software working correctly. Thatâ&#x20AC;&#x2122;s what needs to be measured.

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely It used to be very cool back in the early days of software development and not-so agile project management methodologies to get down to crunch-time at the end of a project schedule. This is when there was only 2-3 days left before the software was to be delivered and there was 2-3 weeks of work left to go. Everyone would hunker down, pizzas would be ordered, cots would be set up and the all-nighters would begin. Great times, maybe. Sustainable? No way. This type of crunch-time schedules became a normal way of working for many developers and created all kinds of issues ranging from burnout to health problems.

Principle 9: Continuous attention to technical excellence and good design enhances agility. This means take pride in your work. Agile teams arenâ&#x20AC;&#x2122;t just a bunch of hacks that are throwing code together to get a shoddy product out the door. They take the time to review their solution, determine the best approach and then implement with far-sighted vision on where the product is going in the future.

Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential. Simplicity is genius. The ability to take something extremely complicated and then make it easy to understand for everyone involved with the project is a true art form. A goal of agile project management is to make this possible more often than not. This many times flies in the face of corporate culture and what ProjectManager.com ÂŠ 2013 All Rights Reserved

2 2

managers are looking for in their employees. They want to see busy-ness…even if they are working on things that are unnecessary and non value-add.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams. Teams that practice agile project management are strongest when they are selfdirecting. There is an aversion to a top-down, know-it-all, hierarchical approach and more of a “we’re all contributors to the solution” approach. Everyone is free to offer suggestions on the best implementation ideas, architectures, requirements and other aspects about the project to make it the best result possible.

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Inspect and adapt is an overarching principle of agile project management. Just because something is written down somewhere or this is the way something has been done for years does not mean that it needs to stay that way. The team should always be asking if a particular way is the best way of doing things. If it’s not then adjustments can be made and the new way can be implemented going forward. The 12 twelve principles above seem to make perfect sense when you look at them in the context of agile project management. However, these were revolutionary principles when they were first introduced. Many have taken these principles and made them their own for the benefit of themselves, their teams, their companies, and ultimately the users of their working software!

2 3

30 Day Free Software Trial There are two key differences between ProjectManager.com and its competitors. The first is that we give you all of the features you need to plan, track and report on projects efficiently. The second key difference is that our competitors charge a high upfront price as well as annual maintenance fees for new releases. Here at ProjectManager.com we offer you all of the features you need to manage projects, at a small monthly price of just $25 per user. That simple! When you sign up to ProjectManager.com, you also get for free: Unlimited Projects 3 Gigs of Document Storage Client Login Free Upgrade to New Releases

Take Action, Sign-Up for a 30 Day Free Trial Today! Take a Free Trial Create your own Projects Sign up to boost your project success Any questions? Email support@ProjectManager.com and one of our friendly support staff will be happy to help. We also recommend a visit our resource library if you would like access to further: project management tips  video tutorials  project management templates

2 4