Tag Archives: project managementmethodologies

Good article: The important things Lesson learned Documentation & Scope Creep.

Posted on by
Reply

 

Scope Creep and Action Reports (SCARs) in Software Projects

Sarma Danturthi, PhD, PMP– May 18, 2016

There is a strange quote that says, “Two things in life are very easy to do. One, walking on water and two, developing software, if the water and functional/user requirements of the software are frozen.” Funny? Right, but those in the software development field know this statement is an absolute truth. What causes the scope creep?

In information technology software development projects (after submitting the initial requirements), a customer is very likely to change and keep changing the requirements—much to the annoyance of the development team. A team writing software is also often negligent in creating the proper documentation or following a coding standard. This article discusses the scope creep that may sneak into software projects and why the creation of project documentation should be made mandatory, whether the project methodology is agile, waterfall, or any other.

Introduction
Jim Davis, a project manager, just started working on a new software development project that’s very similar to the project his team completed last year. A month after submitting the requirements, the customer is now busy adding more changes to the original requirements and expanding the scope of project. To recall how his team dealt with this kind of scope creep, Jim wants to look into the lessons learned document from last year’s project, but he cannot remember where it is. The team’s technical lead left the company and none of the other team members have any idea about what Jim is asking about. Though Jim remembers some of the pitfalls his team had in the last project, he shudders to think that the team has to go through the same route again. A lessons learned document would have helped Jim save hundreds of work hours, but the document is not available. Worse yet, it was probably never created. Jim is now at a crossroads as to what to do with the scope creep he is experiencing and how his team will sail through all the troubles again.

Does the story of Jim sound familiar? This is the story we may discover again and again in the software development life cycle, even though every project manager has heard the rule a dozen times—in every phase of a project, create the action reports and lessons learned documentation, whether all the project management principles are followed to the core or in part.

Let us face it. First, while developing software, every project manager has more or less experienced the dreaded scope creep at one stage or the other, where the requirements keep changing with regular customer feedback even if the project methodology follows an agile, waterfall, or any other model. Second, it is probably an open secret that a majority of the project managers and developers in the field of information technology often avoid creating action reports or lessons-learned documentation, or for that matter, any other technical documentation, unless absolutely necessary. There are several reasons—either valid or invalid—for the lack of (or willingness to create) these documents. This paper discusses these two factors—combined as an acronym SCARs—and tries to reason as to why scope creep may sneak into software projects and why action reports should be made mandatory, however tough a project manager’s stance is. In this discussion, by using the term “action reports,” we should keep in mind that they are to be created and updated throughout the project and do not replace any other existing or required project documentation. Instead, they are helpful in augmenting a project’s success and will prove to be valuable assets en route to continuous process improvement.

Scope Creep
There is a strange quote that says, “Two things in life are very easy to do. One, walking on water and two, developing software, if the water and functional/user requirements of the software are frozen.” Funny? Right, but those in the software development field know this statement is an absolute truth. What causes the scope creep? To find the answer to this question, let us dig a bit deeper into a software company’s infrastructure. A software development firm usually has three different environments—development, test, and production. If we leave out the mom and pop and bed and breakfast software shops (which actually develop software of high quality), a project manager is familiar with these environments. At best, all three environments are on different servers—both front and back ends. But there are also some companies that have only the back end on different environments, keeping the front end intact on only one machine.

The first option is ideal and obvious—to keep everything detached in every environment. Each environment has its own front and back ends, operating system, software, libraries, objects, and so on and so forth.  A great deal of systems administration, maintenance, and coordination among the teams is necessary to keep these three environments functioning. With three environments and a change control board (CCB) in place, the design and development is done first on the development machine and, when complete, the customer is informed about the approaching test on the testing machine. But during and at every stage of the software development project life cycle, the customer is in direct contact with both the project manager and developers and can give feedback with one or more change requests that may pass through CCB.

In the second option of one front end and three different back ends without any CCB in place, the developer just changes his connections to a different machine while developing, testing, or deploying on a public-facing production server. The bed and breakfast software companies do not have the resources or manpower for three separate environments and take their risks with only one. Their deployment may usually be on a paid hosting website or server. This method is a trial and error and is prone to risk, but these shops feel comfortable with the risk they are taking to deploy or rollback their changes as they deem fit.

Except for a large software development firm, it is very common not to have any CCB to approve or reject changes requested by the customer. The reason for not having a CCB is simple—lack of money for the resources, either human or otherwise. In the absence of CCB, the customer and the project manager are in direct agreement on what changes to make. It is also quite common that these requests from the customer to the project manager sometimes are verbal and/or happen on a mere phone call. Once the project manager starts implementing those verbal changes, the customer gets a feeling of being able to wave the magic wand whenever he wants because the project manager has allowed the customer to play the cards.

As surprising as it may sound, the changes are often for inserting a check box, adding or removing a text box, changing text in a message box, modifying what is displayed, how it is displayed, adding a new column to the database table, adding new functionality to the application, conforming a web page to a standard such as ADA/EOE or W3 Standards, and so on and so forth. The project manager, after allowing the customer to have his way, will soon notice that the project is expanding beyond the original requirements and scope creep is becoming a regular pain. This is because before a software package is created, the customer has only a jagged idea of how the software should look, but really cannot tell what exactly it should look like. This is contrary to a civil engineering project—such as construction of a bridge—where everything is finalized at the design stage. More often, even the most experienced software developer and project manager cannot tell ahead of time how beautiful the final software product will be when complete, because one control (e.g., check box) can be programmed to run like another (e.g., radio button) or a developer can design his own user control with a different look, feel, and functionality.

Let us consider an example. A few days before final deployment while testing the code in action, the customer thinks he now needs an additional text box on a web page, in which he can type a note and record it. It is a very simple request that will not take more than fifteen minutes of code changes. At least, that’s what the customer assumes. After receiving this request from the customer, the project manager calls an open dialog in the war room and discusses this change with his programmers. A text box can be created easily, but now the team raises some valid questions. What does the customer plan to type in the box? A free entry text box on a web page can be a land mine for SQL injection attacks. So, the text box requires a validator for data. If we somehow avoided that land mine with a validator, the next question is, where do we store the data typed in that text box? Do we already have sufficient table space on the back-end database for it? If not, how much time and space is required on the back end? Also, if the customer is typing some free text into the text box, when he retrieves the data, should the entered data show up on a different page? Questions galore—and what is seemingly a very simple text box for the customer, quickly becomes a complex scope creep problem for the project team to implement.

The project manager and the development team may start feeling bitter and hostile toward the customer for these ever-changing, unpredictable requirements. On the other end of spectrum, the customer may also have negative feelings toward the project team for not getting the changes he/she wants. Suddenly, every stakeholder recognizes that this scope creep now will have an effect on budget, timelines, etc. The problem in such a situation is lack of communication, since the customer thinks the changes are very simple; whereas the project manager and his team know that these requirements were not mentioned at the start of the project. However, an experienced project manager should be able to handle these things with discretion, dexterity, and diplomacy.

Even in large software development corporations with a fully functioning CCB, this kind of scope creep can happen. When the project manager informs the customer about the possible scope creep and additional costs, if the customer insists on a change at any stage of development with proper change requests through CCB, the project manager will have to budge for various reasons. First and foremost being the fear of losing the business and the goodwill of the customer. Second, the reputation of the company could be at stake. Even if both of these reasons are invalid, we know that a customer can force the project manager to make changes when the customer thinks he “should have his say” in the project. The project manager can find ways to avoid or limit the scope creep by having a boundary for the original requirements and by stating new completion dates, additional costs, pushing the project to another phase, etc. Also, the scope changes can be controllable if done the right way with a certain knack and diplomacy from the project manager. But, as it so happens in software projects, if the customer agrees to the new dates and costs, the project manager has to budge again.

In addition to projecting a smiling face, there are two rules that are repeatedly drilled into the minds of all those working in software development. One, never say no to the customer and two, do not display technical arrogance. Saying no to the customer will lose your business and may cost you your job. Secondly, as a developer or project manager, you may be the smartest person who knows everything from Alpha, Lambda, and Sigma to the most sophisticated rocket science used to send an unmanned spacecraft to Mars, but the customer does not have to know those things. All you need to do is “listen to the customer and comply with what he wants.” There is no need show the customer your abilities to design a space shuttle. In other words, “do what is needed and do not volunteer to do what is not required,” is the official song. These are some of the reasons IT staff always complies and why scope creep may happen—sometimes, at an alarming regularity when dealing with a specific customer.

So, there we have the undocumented first rule—in every software project, be prepared in advance for scope creep to happen. Once recognized and ready—if scope creep happens a few times even after completing several projects successfully—the project manager and his team are at ease to work with a customer and on future projects.

Action Reports/Lessons Learned Documentation
Our next discussion is the creation of action reports or lessons learned documents and adhering to coding standards. As project management practitioners, we all know the real importance of lessons learned documentation and their role in continuous process improvement. We are all brainwashed thoroughly to create lessons learned documents and/or action reports at every stage of the project—not just at the end of the project. But, if we randomly pick a software guy and ask how much time he/she really spends creating any documentation, we know the answer. Software development teams, in general, are very negligent in creating those documents. Large organizations have built-in software, such as Visual Studio’s Team Foundation Server (TFS), to process documentation, but what about the mom and pop, and bed and breakfast joints that cannot afford to buy software for bug tracking, documentation, etc.? Except for the user and operating manuals, there is really no other documentation that is created by those shops. Even after a successful test run, did we actually record the number of bugs found and how they were corrected? Did we document how a difficult bug was eliminated after several days of research and mental toil? If not, once we fixed the bug and have lost track of the process, only the person who did the original work may remember those bugs and their resolutions—and maybe only for a short period of time. If the original coder has moved on to another project or company, the entire knowledge base goes with him or her, just out of the door and into the oblivion. Think of the number of hours one can save and the amount of mental stress one can avoid if only such an experience were properly documented.

Why doesn’t the software team or project manager care much for creating the action reports? There are dozens of reasons. Among them are laziness, lack of time, ever-changing technologies and their versions, the absence of any project management methodology in the project, staff changes, programming language changes, migration to a different environment/framework, or various other financial and social obligations. Yes, the “my-job-is-holier-than-document-creation” factor comes in too.

The other side of the documentation coin is purely technical, much more distressing, and actually happens inside a perfectly functioning piece of code. If we randomly pick a software development business and look carefully within its infrastructure, we find that there is no proper standard that is usually followed for coding—either by the team lead or by those who work with the team lead. Even large organizations give very little importance to coding standards because their focus is mainly on a version of working code rather than properly written working code. There is quite a bit of difference between “working code” and “properly written working code.” A properly written working code is readable, has plenty of comments, follows a pre-defined format, encourages other coders to follow the format, gives insight to the application, class, or objects being created, and makes the life of a coder/reader easy. It also compiles without bugs and runs successfully. On the other hand, a “working code” may function and can, apparently solve the problem, but once a bug is found, anyone other than the original coder will find it increasingly irritating to understand the functioning of the code in order to trace or debug. Even the original coder—after not seeing the code for six months or more—will find his own code very annoying when he comes back to debug. A properly formatted and well-documented or commented code saves time, energy, and avoids frustrations. But when it comes to coding, do we follow a format or a standard? If we do, how good is the format and how often do we document the code? Those are the most important questions for everyone in the software development field. Lame excuses like lack of time or interest for not writing proper comments or for not following a coding format should not be entertained by the project manager. If writing dry code takes a few hours, with a little practice, writing properly written working code can be efficiently done in the same number of hours.

Documenting is a lucid write-up of what we know, what we did, and how well we understand the process. By documentation, it is neither a dry Microsoft Word document nor a lengthy novel, but one that saves our lives. In one sentence, documentation is the life blood of the software development process and is an essential component of successful project management. But, there is a general disregard and alarming indifference to creating documentation for software projects. In his book, Memoir of the Craft – On Writing, fiction writer Stephen King asks all the people who do or want to write, “If God gives you something you can do, why in the name of God wouldn’t you do it?”

Why, indeed! The question applies equally to all of us working in the software field who refuse to create the needed documentation and do not follow any formatting or coding standards. Above all, we need to remember that the greatest advantage of action reports or lessons learned documentation is that they help us in continuous process improvement and in shaping the success of current and future projects.

Conclusion
Those of us working in the software field need to accept the fact that scope creep can happen sooner or later. Even if we have worked in the field for a year, ten years, or thirty years, a customer request will probably push us beyond the original scope of the project. And the best action we can take for creeping scope is to expect it and be prepared for it. Secondly, any action reports created at any stage of software development life cycle—design, development, code, test, or deployment—are going to be life savers, both to the original coder and the successors. The more documentation we have about a project, the better our lives become because these documents provide a mental map of the project and can save us embarrassment and hundreds of hours of time. Documentation also includes having a coding standard and religiously sticking to it while coding. If we conscientiously avoid the documentation for whatever reasons, we know we have an accident waiting to happen—an imminent wound, and an ugly scar when the wound heals. The best way ahead to avoid all these is to remember the acronym—SCARs. We need to be prepared in advance for possible scope creep and action reports. In addition to promoting success in current and future projects, they can expertly guide us in continuous process improvement.

About the Author
R. Sarma Danturthi has a PhD in engineering from the University Of Memphis, Memphis, TN, USA and has taught graduate-level courses in computer science. He has been working in the IT field for several years. His experience includes design, coding, leading project teams, and successful project management. He has also published papers in peer-reviewed journals and has written book chapters on software interfaces, modeling, and simulation. His interests include cloud computing, intelligent interfaces, and mobile application development, among others. He can be contacted at d_danturthi@hotmail.com

PRINCE2

Posted on by
Reply

NASA wasn’t the only government organization working to improve project management. The British government has honed their project management methods for years, cumulating with PRINCE2 in 1989. An acronym for PRojects IN Controlled Environments version 2, PRINCE2 throws sprints out the window, and instead approaches a project as one big sprint and stresses quality of delivery—like a traditional project management version of Six Sigma. The framework is more focused on the ends rather than the means; what’s expected of the end product will determine the scope and shape the planning.

There are three interests at play with PRINCE2: the business interest (is it going to make money?), the user interest (will customers find this valuable?) and the the supplier interest (do we have what we need to make this happen?).

PRINCE2

PRINCE2 has a more clearly defined personnel structure than most project management systems, one that works for larger projects that governments and other large organizations must undertake. Each team member has specific roles, which carry through all 7 of PRINCE2’s stages: Startup, Direction, Initiation, Control, Boundary Management, Planning, Delivery and Closing.

  • Startup: First on the agenda: leadership chooses a project manager and clearly relays everything that they expect the product to be. The PM, whose main focus is the fine details, reports to the project board, which puts together the project’s direction. The project board steers the course of the project and is ultimately accountable for its success. The remaining members make up the team.
  • Initiation: During this step, the project manager writes the “initiation document,” a plan to bring the project into reality. Once the project board signs off, it’s time for the control stage, when the project is divided into phases. These phases don’t have to last the same amount of time; the duration of each is determined by what each realistically demands. Like waterfall, a phase must be completed before moving on to the next one.
  • Direction: It’s not enough to have oversight—you also need to know exactly how a project should be overseen and managed. The direction phase sets the overall management structure for the project, outlines how each stage should progress, and what should happen if something changes along the way.
  • Control: Some amount of change is inevitable, which is why PRINCE2’s per-stage review can be helpful. The roadmap for each phase is determined by the review of the previous one. So while there may have been a general plan, that can be manipulated if a review shows a need for something else. Once again, the project board has to sign off on this—bringing double the meaning to the “Boundary Management” stage.
  • Boundary Management: The management stage looks at product delivery: what is going out (for example, what features will an app keep or chuck?), how it’s going out, and asks, is the product that is going out exactly is what the business wanted, and meets all requirements?
  • Delivery: From a project manager’s perspective, this is where the most important oversight takes place. As work begins on product delivery, the project manager is in charge of making sure that everyone is doing a job that aligns with the project’s goals and getting approvals once parts of the project are completed.
  • Closing: After everything is said and done, the closing stage still remains. Closing is an in-depth analysis of how the project faired. This is put into a report, which also has to be approved by the project board.

That may be a bit much for some projects, so you can still customize the stages for your needs, while still keeping the same general idea of PRINCE2’s structure, planning, and reporting back to upper management. Just like Scrum is a more structured version of Agile, PRINCE2 is a more structured TPM system, with some of the benefits of the Lean approach thrown in.

PRINCE2 strengths

PRINCE2 STRENGTHS

PRINCE2 works best when the stakes are high and there needs to be several pairs of authoritative eyes on the project every step of the way. If you’re big on feedback and guaranteeing nothing will go wrong, this might work well for you.

That’s why PRINCE2 is so popular in government offices—it’s used in the United Kingdom’s government, and is the standard for project management for the United Nations. It’s been successfully used by VocaLink to streamline real-time money transfers between banks in Australia and the UK, something where there is zero tolerance for flaws and where communication is essential.

PRINCE2 weaknesses

PRINCE2’S WEAKNESSES

Despite PRINCE2’s success in governments, it isn’t without its drawbacks. If used in the wrong environment, there’s lots of opportunity for bottlenecks and politics. Because of the extensive reviews and sign-offs, you might end up wrestling for control or find that work is delayed because someone hasn’t signed off yet. And strictly defined roles can stave off a sense of true collaboration.

Six Sigma Project Management

Posted on by
Reply

Six Sigma

Motorola wasn’t about to let the auto industry take all the credit for project management innovation, so decades after Toyota’s introduction of Kanban, the mobile phone company’s engineer Bill Smith created Six Sigma in 1986. It’s a more structured version of Lean than Kanban, one that sets specific stages and adds in more planning to save resources, ship quality products, and eliminate bugs and problems along the way.

The ultimate end goal is to make customers happy with a quality product, which is done through continuous improvement heavily reliant on data analysis. You ship parts of your project along the way, while at the same time address product pitfalls that come up—something very similar to the Apollo project’s workflow.

six sigma

This is accomplished through Six Sigma’s five steps, known as “DMEDI”: Define, Measure, Explore (or analyze), Develop (or improve) and Control.

  • Define: This first step is much like the initial steps in other project management frameworks. Everyone determines the scope of the project, gets information from all sides, and determines what the business goals are (for example, sales).
  • Measure: Because Six Sigma is big on data, the measurement stage establishes the nature in which the team will calculate progress—your overall goals. Seeing the rate of success—the value to the consumer as well as the business—as a quantifiable thing is at the core of Six Sigma.
  • Explore: During the exploration stage, it’s up to the project manager to figure out the ways in which the team can meet and exceed product requirements. This keeps you from going over budget and missing deadlines. If something didn’t work last time, it’s likely not going to work this time, so project managers (PMs) have to be adept at thinking outside of the box.
  • Develop: It’s only at this fourth step is a strategic plan is put in place. And it’s a detailed one—anything that will or might be needed to get the job done finds a place somewhere in this plan. Most of the project’s momentum occurs here, because you apply the plan, work on the next project map, and measure results as you go.
  • Control: The last stage is about long-term improvement, which is what a Six Sigma project strives for. A documented review full of lessons learned is applied throughout the company, and to future projects, as well.

It’s much like a Kanban approach, only this time with set stages for the project that make you plan, define goals, and test for quality at each stage. You’ll likely end up with more meetings than Kanban calls for, but you’ll also have a far more structured way to approach each task. And just like Kanban, you can customize the phases for what your project needs—you’ll just need to keep the measure and control steps in place if you want to learn from past projects and continually improve your processes.

Six Sigma strengths

SIX SIGMA STRENGTHS

Six Sigma runs a tight ship, which can help you continually improve your processes and ship better results. By defining the goals and then reviewing them later, you’ll have objective data to measure project success with—something that’s far better than just going on intuition. While gathering and learning from data can take up a significant amount of time, you’ll be able to learn from what you’ve done and improve your work in the future—and that’s where time and quality savings should come in.

There are plenty of scenarios in which the job is never really done—that’s where Six Sigma shines. It helps you ship your tasks, learn from them, and improve the next time around.

Six Sigma weaknesses

SIX SIGMA WEAKNESSES

Project manager seem to have similar gripes about Six Sigma: cost savings are the goal but not guaranteed since customer satisfaction will take precedence. If you’re continually adjusting your goals with each task in the project, it’s easy to let things spiral out of control even while you’re trying to ship your best possible work.

Then, Six Sigma’s underlying motto that good is never good enough can be frustrating for some, who may feel like the ghost of continuous improvement never brings them the satisfaction of finalizing a job well done. Some project may only be done once, and the focus on metrics and incremental improvements may seem unnecessary there.

Mengenal trend : KANBAN Project Management

Posted on by
Reply

introduction: Simple Kanban board , basic source From Wikipedia, the free encyclopedia with self modified

A kanban board is one of the tools which can be used to implement the kanban method for a project.

Did you remember  Post it- 3M?

Kanban boards are perceived as a variation on traditional kanban cards. Instead of the signal cards that represent demand or capacity, the board utilizes magnets, plastic chips, colored washers or sticky notes to represent work items.[1] Each of these objects represents an item in a production process as it moves around the board. Its movement corresponds with a manufacturing process.[2] At its simplest, the board is usually divided into three sections: “awaiting production”, “work in progress” and “completed work”. Complex Kanban boards can be created that visualise the flow of work across a value stream map.[3] Employees move cards to the section on the board that coincides with the receptacle it represents.

A simple kanban board,

Application

Kanban can be used to organize many areas of an organisation and can be designed accordingly. The simplest Kanban board consists of three columns: “to-do”, “in progress” and “done”. Business functions that use Kanban boards include:

The most popular example of kanban board for agile or lean software development consists of: Backlog, Ready, Coding, Testing, Approval and Done columns. It is also a common practice to name columns in a different way, for example: Next, In Development, Done, Customer Acceptance, Live.
  • Kanban for marketing teams
  • Kanban for HR teams
  • Organisational strategy and executive leadership teams
  • Personal task management or “Personal Kanban as described and promoted by Jim Benson.
  • Audit teams

Principles

  • visualize workflow
  • limit the number of tasks under “in progress
  • pull work from column to column
  • monitor, adapt, improve

kanban

Tupalo’s Kanban board

 

Lean sounds a bit abstract on its own, but combine it with Kanban and it’s easy to build your own Lean project management system. Conceived by Toyota engineer Taiichi Ohno and implemented in 1953, Kanban is set up much like a factory floor, where a part might start out as a piece of metal and then, one step at a time, is turned into a finished part through a series of steps. In the same way when using Kanban, you’ll do some work towards a project, then ship that item on down the line to the next station where something else is done.

Kanban also pulls inspiration from the grocery store model: for maximum efficiency, carry just enough on your shelves to meet customers demand. So, in Kanban, instead of plowing ahead on shipping a complete project, you can leave tasks at various stages until they’re needed—whether that’s half-made, low-demand parts in a factory, un-edited blog posts in your queue without a publish date, or anything else that’s waiting for a need in your workflow.

It’s a lot more laid back than Scrum—there’s no set time for sprints, no assigned roles outside of the product owner, and a zen-like focus on only the task at hand. You could have meetings about your overall projects, or not: it’s up to your team’s needs.

kanban

All you have to do is define the stages of your workflow, then setup a way to move each task from one stage to the other. In a factory, you might have different boxes or shelves for each stage: raw materials in the first, half-made parts in the second, and completed parts in the third. For other projects, you might have a card—whether a note in a program, or a physical piece of paper on a board—where you list info about a task, and you’ll move that card to different lists as the task progresses.

Your Kanban system can be as flexible as you want—it’s really just a way to visualize the Agile idea—but there’s four pillars of the Kanban philosophy that can help make sure your projects get shipped. These include:

  • Cards (Kanban translates to “visual card”): Each task has a card that includes all relevant info about it; this makes sure everything to complete the tasks is always at hand.
  • Cap on work in progress: Limit how many cards are in play at once; this prevents teams from over-committing.
  • Continuous Flow: Move down the list of backlogs in order of importance, and make sure something’s always being worked on.
  • Constant improvement (otherwise known as “kaizen“): Analyze the flow to determine how efficiently you’re working, and always strive to improve it.
Kanban strengths

KANBAN STRENGTHS

Like Scrum, Kanban fits best with a highly cohesive team that knows what it takes to keep the flow going—but unlike Scrum, it’s designed for teams that are self-motivated and don’t need as much management or deadlines. It’s great for those who lean toward seeing the entire project at a glance.

While the two-week Scrum rule is absent and subprojects can take however long they’ve been given, you should still have an overall focus on efficiency—which should help save resources. If you’re careful to follow Kanban rules and only assign as much work as a team can handle, projects are less likely to go past deadline and team members are less likely to juggle other distractions. And because the product owner can change tasks that aren’t currently being worked on along the way, it allows for flexibility without frustration.

Kanban weaknesses

KANBAN WEAKNESSES

If only one of your team members has a certain in-demand skill, the individual can hold up everything. Kanban is ideal for teams that have members with overlapping skills, so that everyone can pitch in and help move the backlog list to zero. It’s also best for places where time on the overall project isn’t quite as crucial; if you must ship by certain deadlines, TPM or Scrum give you the time management structure you need.

SCRUM

Posted on by
Reply

Arguably the most structured framework of the Agile methods, Scrum was firstintroduced in the 1986 as a way for “teams to work as a unit to reach a common goal,” according to its inventors Hirotaka Takeuchi and Ikujiro Nonaka. Scrum takes parts of Traditional and Agile project management ideas, and combines them for a structured yet flexible way to manage projects.

Like Agile, Scrum breaks projects up into tasks that are completable on their own, and then assigns each a “sprint”—two to four-week slots of time dedicated to ship that phase of the project, with daily sprints to ship some part of that phase. It’s that focus on time that makes Scrum a bit more like TPM, bringing more structure to the Agile idea.

scrum

Then, to make sure the project is progressing as expected and meeting goals that may have changed along the way, Scrum requires a reassessment—and potential project changes—at the end of each sprint. It also divides responsibilities into three roles: the Product Owner (PO), the Scrum Master and the Team.

The Product Owner, who should be deeply familiar with all aspects of development, makes sure that everything aligns with business goals and customer needs with a mile-high view of the overall project. The Scrum Master is the team cheerleader—a liaison between the PO and the rest of the team—who makes sure the team is on track in each individual sprint. The Team then is the people working in each sprint, dividing the tasks and making sure everything is shipped.

With all this management and focus on deadlines, Scrum’s main structure revolves around 5 meetings: Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

  • Backlog Refinement Meeting (also called “Backlog Grooming”): This meeting is much like the planning phase of TPM, and is held on day one of each sprint—you’ll look over the tasks left in the project, things left behind from previous sprints, and will decide what to focus on. The PO makes the call on how to prioritize tasks, and this ultimately determines how efficient the sprints are.
  • Sprint Planning Meeting: Once the PO decides what to focus on, this meeting helps the team understand what they’ll be building and why. You could share “user stories,” describing features from the customer’s point of view, or could simply divide tasks for each team to work on during the sprint.
  • Daily Scrum Meetings: Simple daily meetings that should only last about 15 minutes, Scrum meetings are a way for team members to update each other on progress. This meeting is not the time or place to air issues—those will go to the Scrum master outside of the daily meetings—but instead is a place to keep the ball rolling.
  • Sprint Review: Since a potentially shippable item is expected at the end of each sprint, the Scrum framework naturally places an emphasis on review. Team members will present what they’ve completed to all stakeholders. While this meeting pushes accountability, its goal is to make sure that the sprint’s completed items match up with business and user goals.
  • Sprint Retrospective: Held immediately after the sprint review meeting, the Sprint retrospective is full of collaborative feedback. Looking at successes and hold ups, everyone decides what is working (what they should continue doing) and what isn’t working (what they should stop doing). This should inspire the focus of the next sprint.

Where other project management systems might look like they simplify your projects and make them seem more manageable, Scrum can at first glance look overwhelming. You’ll need to delegate responsibilities and plan extra meetings—but that overhead can help ensure your projects are successful and stay on track. It’s a structured way to make sure everything gets done.

scrum strengths

SCRUM STRENGTHS

Scrum is designed for projects that need parts of the project shipped quickly, while still making it easy to respond to change during the development process. With so many meetings and ways to delegate tasks, it’s also great to use when parts of the team may not be as familiar with a product’s context (i.e. developers from different industry backgrounds working on a system for the financial sector). You’ll always have someone looking out for the project as a whole, so if each person on the team doesn’t understand the entire project, that’s OK.

Netflix is a great example of Scrum’s ability to help you ship fast. It updates its website every two weeks, and Scrum was a good match because it stresses the user experience, eliminates what doesn’t work, and leaves a small window of time to get things done.

For each site iteration, the designers would test new features, forget the ones that didn’t work out and move on to new functionalities. Most of the benefits the Netflix team saw with Scrum was the ability to “fail fast.” As opposed to launching one massive redesign with many components, their bi-weekly incremental design changes were easy to track; if something went awry, they knew exactly what it was tied to—and could fix it, fast.

scrum weaknesses

SCRUM WEAKNESSES

Like Netflix, you may experience downfalls of Scrum, such as upset designers who saw their beloved work chucked after testing showed it didn’t work—especially when the testing comes so quickly and some may feel that the new ideas would work with more time. You might also have trouble adjusting if your team is accustomed to long release cycles—or, depending on your work, you might find shipping so often isn’t necessary.

Scrum’s meetings and management overhead can also be overkill for some projects, turning into something where you’re more focused on planning sprints than you are on actually getting work accomplished during them.

Lean

Agile project management dictates that you break your work up into smaller, shippable portions, but it doesn’t say much about how to manage each of those portions of your project. Scrum tries to fix that with managers and meetings; Lean, on the other hand, adds workflow processes to Agile so you can ensure every part of your project is shipped with the same quality.

With Lean project management, you’ll still break up your project into smaller pieces of work that can be completed individually. You’ll also define a workflow for each task, something that’s reminiscent of the Apollo project and its five box system. Perhaps you’ll have a planning, design, production, testing, and shipping phase—or any other workflow of phases that you need for your task. Cooking a meal might need a preparation and cooking step, while a writing workflow might need an editing and fact-checking step.

lean

Lean’s stages and their flexibility make it a great system for making sure each part of your project is done well. It doesn’t have Scrum’s strict deadlines, or force you to work on one thing at a time as TPM does—in fact, you could have various tasks in various phases of your Lean workflow at the same time. What it does do is let you build a system tailored to your team.

Just like Agile, Lean is more of a concept than a set-in-stone project management system. You can use the Lean ideas, and build the system you need for your projects.

lean strengths

LEAN STRENGTHS

If you liked the idea of Agile, but wanted a way to make sure each part of your work is consistently finished with the same level of quality and oversight, Lean gives you the extra tools you need to make that happen. It’s still flexible—you can define the stages of your project portions as you want—but there’s enough structure to make your projects a bit more guided.

lean weaknesses

LEAN WEAKNESSES

Every part of your project doesn’t necessarily need the same level of oversight or the same steps for completion, but lean treats everything the same. That can be one major downfall in using it to manage projects with diverse parts that all need completed.

Lean also doesn’t have any process to make sure the final project is completed, making it easy as it is with Lean to let your projects drag on forever. It’s again something communication can clear up, but it is worth keeping in mind.