In a perfect world, every time we rolled out code at the end of a sprint, it would work perfectly in production. There would never be any bugs, and there would never be any issues that forced us to roll back code that has already been deployed.
Of course, we don’t live in a perfect world. That’s one of the reasons why we have agile in the first place. Agile isn’t about pretending that your world is perfect. It’s about adapting to reality, and iterating to improve your processes and your flexibility so that when problems arise you’re able to deal with them.
One of the problems that comes up frequently for teams is the discovery of a new bug in production right in the middle of a sprint. Your team has finished deploying, all the tests passed, and everything has been pushed out to production so customers can start using it.
But maybe an edge case that wasn’t considered comes up. Maybe some aspect of the code that wasn’t fully tested comes to the surface, and starts causing problems for users. How’s your agile team supposed to respond to that?
Read the rest of “4 Agile Ways to Handle Bugs in Production” on SitePoint.
]]>One of the most interesting parts of our conversation had to do with Epicurean Materialism. He brought up the topic (Did I mention he’s a very bright guy?) and explained it to me from his perspective, and told me his life had been directed since he was a child by the philosophy that one should focus on an objective, get on the path to that objective, and ignore distractions until that objective has been met.
As an agile practitioner, I recognized that immediately as pretty similar to waterfall, which involves setting a sequential planning into motion with a clear objective at the end and a detailed plan for how to get there. In a waterfall context, you adjust reality to meet the expectations of the plan, not the other way around.
What he anticipated was that he could reasonably expect that so many years of school at some highly-ranked institution with such-and-such grades would lead cleanly to a particular job with a particular title in a particular organization. And because this is what he had seen his family do for generations, and what his friends were doing alongside him, he had come to believe that it would work that way.
For him the objective of getting a particular degree from a particular college was the path he had been working toward since he started high school. It wasn’t an easy path by any mans, but on the advice of advisors, family, and counselors, he was choosing to treat the challenges as distractions and press forward toward his one objective.
I think the reason he came to talk to me was because he knew I would listen to him with a perspective that wasn’t tied up in family or professional bias. Despite the clarity and all-encompassing nature of his focus, my friend told me he was starting to believe that the distractions he was facing might actually be red flags. It seemed likely to me that he was noticing the turbulence of the economy and the shifting of geopolitical power, and projecting quite reasonably that things may not remain as stable as they may have appeared for the luckiest members of earlier recent generations.
Just having the luxury of being able to choose whether or not to pursue an education is something valuable. As with everything else in life, it helps if you’re privileged with a gender, race, orientation, financial status, physical constitution, etc. that don’t put you at a significant disadvantage for what you want to do in the society where you live. When discussing how much preparation you need before you can compete and thrive in the professional world, it’s never fair to assume everything else is equal. Matters such as these always need to be considered in the context of privilege.
Being a friend, I didn’t think it was my place to encourage or discourage him about his education. But I thought it was important for him to take a step back and consider what his own objectives were before plunging headfirst into that path. In some cases, what he was looking for matched exactly what you get from a good college education. The thing that struck me was that many of these weren’t the benefits that he expected to get from college.
Like a lot of prospective college students, my friend was being sold the idea of an education as the opportunity to get a degree and use it to get a job, at the cost of several years of his youth. But in my experience as a lifelong student, a good education is not about the piece of paper they hand you at the end. That may be the prize they offer you to get you in the door, but if you approach college with an agile learning mind, you can come out with so much more.
College provides a rare opportunity to get constant and critical feedback on the work you’re doing while you’re doing it, without horrendous consequences. Yes, bad grades and humiliation in front of a classroom full of your peers may seem like horrendous consequences, but they are nothing compared to losing your health insurance, seeing your family go hungry, or getting kicked out of your home.
One of the principles of agile is the importance of getting quick feedback and using it to make adjustments to your process.
I’ve heard people say that the advantage of having somebody qualified who is there just to hold your hand and tell you honestly what they think of your work is worth the cost of tuition alone. In the real world, you often have to struggle to figure out whether or not what people are telling you is based on a different agenda than the one that may be obvious. In college, the people judging you and giving you feedback usually don’t have agendas that go too far beyond the scope of the syllabus. That opportunity to get quick feedback and adapt to it since you up to grow quickly.
No matter where you go, you’re sure to meet other people who can help you, and who can benefit from your help. Helping each other is one of the most valuable ways to grow and learn. At along the way, if you become a valuable resource to other people, they will see the benefits of doing the same resource for you.
A core principle of agile is prioritizing face-to-face conversation over dry abstract documentation, and that means knowing how to interact comfortably with a wide network of real human beings.
College exposes you to a broad selection of people looking to make a change in their skills and their status. These are people who have signed on and accepted the challenge. Where they go next in life builds naturally upon the way that they approach their studies, and as a fellow student you get a front row seat to watch their progress and apply the lessons they are learning to your life.
Being a student gives you the opportunity to meet tomorrow’s professionals today, before they’ve funneled themselves into a career. As fellow students, you are peers today, regardless of where your work takes you in the future. You have a perfect excuse to meet and make friendships with other people who are also on a growth path. College is a great time to connect with the people you will be doing business with for the rest of your life.
The nature of being a student is having an open mind and learning new things. We spend our childhoods being taught traditional subjects such as math, science, languages, and social skills, but the meta-lesson is how to walk into a new subject without any experience or knowledge, and walk out with a skill.
Agile teaches us not to take our process for granted, and to revisit what we’ve learned regularly to make sure the lessons still apply as our context changes.
It takes courage, and a willingness to try something, fail, try again, notice what changed, and adjust. No matter how high we may think the stakes are when faced with the prospect of bad grades, the protected environment of college is a beautiful place to let oneself fail at something large and complex, and notice what happens.
The most important point to keep in mind is that it’s your life. You can always go back and change your mind if the situation calls for it. None of us knows how long we have. Life is about adaptive capacity; the ability to make a choice, try it out for a few years, and if it doesn’t work out you try something else. Some choices do require postponing the reward you desire in order to put in the time necessary to explore an idea, get educated, and develop skills. And sometimes you decide along the way that other opportunities are more appealing, and let go of old dreams.
Time is the one resource none of us can replenish. Unless you have an urgent and pressing need that removes your choices for you, it’s always worth taking a step back before you start down a new path to consider whether the distant goal you’re working toward is worth the investment of these precious years of irreplaceable time. And for a young mind maturing in an uncertain world, it’s unreasonable to expect that the plans made for the child will still be appropriate after graduation without and adjustments.
]]>If you’re developing a prototype that you plan to show the client, you probably need feedback from them about how that prototype is behaving. You certainly don’t want to create any unrealistic expectations about the state of development based on the state of the prototype.
Tell me if you’ve been in this situation before: you’ve been working with the designers to mock up a prototype of the user interface for the web or mobile application you’ve been asked to build, and as soon as you present it to the clients, they start asking how close it is to being done. After all, the prototype looks great and it’s fully functional, so it can’t be that long before the product is ready, right?
In the mind of the client, it make sense. They’re not experts on development, they just want something done. The reason they hired you was because you understand all the stuff that goes on behind the user interface. As far as the client is concerned, that user interface is the actual product. How can they be expected to know that the prototype you’re presenting doesn’t have all the security features and performance optimizations necessary to make the product complete, or how much additional work that’s going to take?
There are a few things you can do to help make it clear to the customer when showing them the prototype that that’s exactly what it is; a prototype. A lot of it comes down to managing expectations effectively, rather than trying to explain the differences. You don’t want to sound as if you’re making excuses. But if you haven’t communicated how different a prototype is from the finished product, you can’t expect the customer to understand.
So here are five tips you might want to keep in mind when you’re about to show a prototype to a client:
One of the reasons your clients may be confused by prototypes is that they don’t understand the difference between a prototype and a finished product. All they see is the surface, and that’s going to distract them from being able to provide you with the feedback you need. The closer your prototype looks to the finished product, the more likely they are to focus on the alignment of the borders and the color of the shadows than on the fundamental behavior. To avoid that, keep the artwork as basic looking as possible. As long as the prototype doesn’t have clean and refined visual design components, there’s no way the client can confuse it with the finished product. Using rough, sketchy styles for the fonts and iconography will help you keep the focus of the prototype review on the way to protect behaves, rather than on the color of the submit button.
It’s easy to forget these days how much you can get accomplished with just paper and pens. By representing your product or service using index cards or sheets of paper, indicating on each piece what actions the user can take and what happens next, you can present an interactive demonstration without any code at all. You’ll also avoid wasting any engineering time on mocking up prototype code. The important thing is to show the client what’s in development, and get their feedback in a way that lets them participate without any confusion about the state of the product itself. (Unless of course you promised them a stack of paper as the final product, in which case all bets are off.)
We’re all fond of our slideshows for giving presentations, but the power of these tools also lets you go pretty far toward prototyping the behavior of many basic web and mobile products. Depending on your slideshow skills and what you’re developing, you may be able to do everything the final product needs to do visually using just slides, media, and transitions. And it will be easier to communicate the idea that these are just slides and transitions, rather than actual working code.
If your prototype is more complicated than something you can put together using slideshow tools, there are visual interactive prototyping tools such as InVision, Adobe Comp, or Origami. There are plenty of them out there, and most are pretty easy to learn. These tools give you access all of the interactive power of mobile devices or web browsers, and allow you to create interactive walk-throughs that are very clearly not finish products because of the flat or simple nature of their visual design. Some of these services also let you give clients remote access to play with the demonstrations directly, although it’s important not to give them access to make changes. Keep the information pipeline under your control, and don’t let random input alter the client’s expectations or your engineering team may suffer the consequences.
Most prototyping tools use simple grays blacks and whites, avoiding any color at all, to make their output look different from a finished product. However there are clients who like that look. What’s considered ridiculous will vary from one client to another. Figure out what aesthetic your client prefers, and use colors that violate those standards. For web component prototyping, I’ve been known to create a CSS class named “.fpo” (a reference to “for-placement-only” graphics used in print publication). I add this class to any element on a prototype webpage that is clearly not complete, so the client won’t have any confusion. For example, once I created a .fpo class that added garish pink and purple diagonal stripes to any element that was on the page just for placement purposes. The client’s website aesthetic used a lot of soft shadows, pastel colors, and muted grays. There was no confusion.
While I do recommend using inappropriate colors that stand out, I don’t recommend going much further than that. It can be dangerous to include prototype text and graphics that may be amusing to your developers, but may get the client into trouble if they’re missed in the handoff and end up somehow appearing in the final products. You don’t want Beyoncé’s lawyers calling you up because you forgot to remove her likeness from one of the screens of your app. It’s amazing how easy it is for temporary elements in the prototype to become part of the production release. Consider yourself warned.
No matter how careful you’ve been to set reasonable and realistic expectations during initial negotiations, the client is always going to try to push for faster delivery. After all, they can’t start making the money that they need to pay you until they have the products that you’re building for them.
Keep control of the situation by holding off on the visual design. Use paper mockups when you can, or use slideshows or prototyping tools when you need something more sophisticated. Don’t forget to distinguish the prototype with colors and patterns that will stand out from the client’s visual design aesthetic. But be careful not to use elements that could get the client into trouble if they ended up in the final product because somebody missed them.
Be realistic and reasonable, and never let them think that the prototype that they’re evaluating is anything more than a feedback mechanism.
]]>Very excited!
]]>The issue here is not really about tracking work on bugs. The problem is that it’s impossible to reconcile the client’s desire for bug fixes against the team’s agile agreement to complete a specified slice of functionality each sprint.
Agile doesn’t care about the contract with the client.
One of the reasons an agile scrum team always has a designated Product Owner is to insulate the team from the issues that come up when dealing with the client. It’s irrelevant to the agile process how the contract was written, or what the client calls a bug. Agile is about determining what the team can sustainably deliver, breaking requirements down into deliverable slices of functionality, and helping the team get better at estimating those stories.
The client doesn’t get to decide what is a bug; only what is acceptable. Under no circumstances should the customer have any part in defining “done” for the team. And under no circumstances should the agile process have an opinion about what the client is paying for or what is acceptable.
The Product Owner represents the interest of the client, and works with the team to create stories that add up to the number of points the team is historically capable of delivering during a sprint according to the team’s velocity. Whether a story is treated as a bug, and not assigned points, should only be based on the state of the product at the beginning of a sprint, not on the client’s arbitrary definition.
If a story involves taking the state of the product at the beginning of a sprint and changing it in a way that is visible to the end user, that story is feature development and gets estimated with points.
On the other hand, if a story is delivered during a sprint but not accepted as done because it does not meet the acceptance criteria, fixing the code so the story can be accepted is bug work. No points should be counted for bug fixes, regardless of whether the work is done in this sprint or the next.
Bugs in agile reduce velocity because the team was unable to deliver working functionality, not because the client calls the product’s behavior buggy.
Agile can help the team realize what they are capable of in a sustainable manner. It’s up to the people who write the contracts whether it makes more sense to go with a fixed price for a fixed scope, or structure the deal around some sort of warranty. The team can only deliver what it can deliver, regardless of the contract.
If you’ve found yourself wrestling with this issue, check again and make sure whether you’re talking about agile bugs or what a user might consider buggy behavior in a product. They’re different beasts, and they need to be treated differently. I’d be interested to hear your experiences with bug definitions, and how you communicated them to your team.
]]>Is it possible to keep your developers productive once they’re finished with the development work for a story, and avoid stressing out your QA engineers at the same time?
The definition of done must include testing if your company is at all concerned about quality, so the story produces a slice of complete functionality for the product at the end of the sprint. And the team must committed to delivering what they agreed to deliver, even if it means working outside of their discipline.
Ideally, a team won’t be limited by job titles and roles, and will be willing to work together on both development and testing to complete stories. If the developers are getting so far ahead of QA that they are working on the next story before the current story is done, then they are missing the point of working together as part of a scrum team.
Keeping QA isolated comes at too high a cost. The fact that all members of a team may not be coloated shouldn’t prevent the team from working together as a unit. There are so many excellent remote collaboration tools such as Screenhero or Google Hangouts, or even BitBucket and Github for asynchronous coordination. that there’s no excuse anymore to let geography prevent teams from working together across disciplines.
It is to the benefit of the developers to work closely with QA to establish the standards by which the development work will be evaluated. And it is a growth opportunity for QA to work closely with the developers, both to learn the skills of development, and to make sure the requirements QA will be testing for are considered.
A team that does speculative development on new stories before previous stories are tested is not getting more done; they are just building up a backlog of untested code that cannot be shipped. It is not to anyone’s advantage to work on a new story until the previous story is actually finished.
Do not allow the developers to get ahead of QA with untested code. A story isn’t done until it is done. It is everyone’s responsibility to make sure every story meets the definition of done before moving forward.
]]>You’re not alone, and the problem isn’t you. Getting a job as a scrum master is not impossible, but it’s also not always a direct path. There are a few tricks to keep in mind, and knowing them will take you further than hours of scrubbing through job boards or making friends with recruiters and HR managers.
Here are some important points about the way companies get competent scrum masters, and how you can secure a position that will benefit you and your next employer.
The position of scrum master is often one that gets filled by members of an existing team as they transition from a less agile process. Scrum doesn’t magically appear in an organization. It usually is birthed from the pain and suffering of a team that realizes it can’t get anything done without a significant shift in their process. That realization may come in the form of a natural servant-leader who heads the charge toward agile, and slides gracefully into the role of scrum master.
If you are looking to work for companies that are just transitioning to agile, you may have a tough time finding open listings for jobs as a scrum master. For many of these companies, the role of scrum master will be filled from within the ranks, and may have to prove its value before it gets funded to the point of hiring trained outside professionals.
Jobs are usually brought into existence by the managers who see a need on their teams, and who can justify the expense of hiring someone new. However, the actual job descriptions and titles are often dictated by Human Resources, where titles such as “Scrum Master” may not have an official designation that can be added to the database.
You may need to look for jobs with titles that sound more like traditional project management (or even product management). But scan the descriptions for hints that the company is actually looking for someone familiar with agile and scrum. Don’t let the fact that the title doesn’t match your idea of what you want to do stop you from applying. Once you talk with the company, you will get a sense of whether you are a good match for what they need.
Is there a particular company you want to work for, but you know that they are not currently following and agile process? Or are you currently working at a company where scrum could make a difference? Don’t let the status quo stop you if you have good reason to believe that the company you want to work for would be open to a change.
The question to ask yourself is whether you truly believe that shifting that company’s approach to be more agile is possible given what they are doing, and in the best interests of the team and the organization as a whole. If your research gives you the confidence to say that with convition, don’t hesitate to schedule an informational interview with a potential hiring manager, regardless of whether they currently have an open job listing for a scrum master.
Approaching a company that isn’t currently using scrum can be a bit of a gamble. Proposing a major change at a company you are already working for can also be challenging. But showing up to an informational interview with a full portfolio of tested processes and procedures, and offering your expertise, might just open doors for you.
Once a company has a working agile process in place, the team and the organization can often support scrum with a single scrum master for multiple teams, or with a part-time scrum master who also holds other part-time roles. The good news can be that companies like this have already committed to scrum and the team is already well trained.
It’s fine to take on responsibility for more than one scrum team, as long as you have the opportunity to talk with the teams and see that their processes aren’t broken. If you interview for a role that is only part-time scrum master, and you get a sense that the company is just trying to cut corners with a low committment to scrum, you might want to keep looking.
If you keep these issues in mind, your job search may be much more flexible. You must remember that you are interviewing your future employer just as much as they are interviewing you. Make sure you are in a place where scrum can survive and flourish. Without that, you might just be working against your own best interests and those of the people around you by trying to support an agile process.
I want to hear how your job search is going, and what obstacles and opportunities you’re finding at the companies you explore. The job market is constantly shifting. It’s invaluable to stay informed, and let your network know what you’re finding.
Stay in touch! Sign up below for the Agile That Works mailing list to be connected to the community and get the latest lessons as soon as they are released.
]]>Sometimes the question comes up about who should be invited to attend standups. Some teams feel uncomfortable when people unfamiliar with their process attend. For example, I recently came across this comment from a concerned scrum team member discussing his team’s feelings about visitors at standup:
“When someone from outside the team wanted to join in, especially any Manager/Sr. Manager, the team wasn’t really happy.”
One thing that impressed me about the comment was that it was about how the team feels, rather than trying to determine the “right” or “wrong” way to manage standups. This is always the bottom line when it comes to a question like this. And the place to get those concerns voiced is, of course, during a retrospective.
Most of the teams I’ve been scrum master for have appreciated any outside interest in what they were doing. It’s validating, it exposes the team to the broader organization, and it supports their career development within the company. As long as the observers are polite guests and don’t try to interfere, it usually adds a lot of value. (And as scrum master, it’s important not to be shy about enforcing the rules of the standup in a gentle but firm way.)
I’ve even gone so far as to campaign for people from all parts of the organization to come and observe our Scrum process in action. Afterward, I often solicit feedback from attendees. It’s a great way to find out what they noticed from an outsider’s perspective, and gather learnings for future improvements.
The standup is for team members, but by tradition a standup meeting is intended to be open to anyone who wants to attend. Only team members should participate, with everyone else observing and holding any comments or questions until the entire team has had a chance. This is part of the transparency of scrum, and if it makes anyone feel uncomfortable, that is a signal to look for other deeper issues.
I’m curious how you approach this issue in your own scrum teams. Let me know. And if you want to read more about issues like this, feel free to sign up below and get new lessons and insights about agile that works for free as soon as they’re released.
]]>Transparency is one of the key advantages of using an agile process, but what do you do about transparency for people who aren’t part of the team? What happens when the executives drop by, look at the burndown chart or the scrum board on the wall, and start asking team members questions? What information can you provide people outside the team to let them know what the team is working on without disrupting the team, without inviting micromanagement, and without interrupting your sprint?
First of all, congratulations on having people outside the team interested in with the team is doing. That’s a big win for any technical organization. Now that you have their attention, one of the great things about agile is that it provides you with a number of artifacts that can be used to explain exactly what the team is working on to anybody, regardless of their background.
Here’s a quick and easy cheat sheet of artifact you can assemble after each sprint, and explanations you could give to people outside the team, to help them understand what you’re working on. (And the best part is, if you’re following your scrum procedures consistently, you should already have everything on hand ready to go.)
At minimum, providing these three key pieces of information at the end of every sprint will go a long way toward helping everyone outside the team understand what the team is working on:
1. Working Software
If your team is building complete slices with working software at the end of each sprint, showing the executives exactly what the state of the product is at the end of the sprint is one of the best ways of demonstrating what you’re working on. Even if your company doesn’t release the product after each sprint, working software with new customer-facing features is tangible evidence of what you’ve been producing.
2. Burndown Chart
A properly updated burndown chart shows the progress of all the stories in the last sprint. One of the advantages of the burndown chart is that it goes from top left to bottom right, unlike many business charts that are expected to go from the bottom left to the top right. Once you’ve explained to non-team members how to interpret the chart, it will provide them with a quick overview of the effort the team put in, and what was accomplished.
3. Retrospective Highlights
The detailed notes from a Sprint respective are usually for the team members only, but issues can come up at the sprint retrospective that are worth sharing outside the team. At the end of the sprint, go over your retrospective notes, and collect interesting data points that are worth sharing with the executives. For example, you might want to make a list of the blockers that came up this Sprint, Along with some of the biggest wins, and the greatest learnings from the sprint.
Bonus: Ask What They’re Looking For
The most important thing is to find out what people outside the team are looking for. You may not want to present the exact same information to everybody, but you want to make sure that everybody who relies on the team understands what’s relevant to their area, so they can provide the support the team needs going forward.
Make it a regular practice to compile this information, and provide it directly to the executives and other key players around the company who are most important to the functioning of your team. if you do this on a regular basis, everybody will know what your team is really doing, and they won’t need to interrupt the flow of the working developers in order to find out.
Again, congratulations on having people outside the team interested in what your team is doing! If you found this technique useful in your work, please let me know about your success, and sign up below to be the first to learn the latest agile techniques I publish.
]]>There can be a strong impulse toward choosing the approach that offers the fewest differences from what hasn’t really been working so far.
For some companies, “getting agile” means sprinkling a few new titles and terms around without really changing how the work gets done, and calling it agile. It’s worth giving your team a chance to follow a legitimate agile workflow first, all the while paying attention to what works and for whom.
Two of the most popular approaches to agile workflow are Scrum and Kanban. Since they are both agile, there are many similarities between the processes and tools you use when implementing either. But Scrum and Kanban provide a different set of advantages that are optimized for different applications.
Read the rest of my article about Should Our Agile Team Use Scrum or Kanban? on SitePoint.
]]>One of the most confusing things about agile may be the fact that we call the estimated units of complexity and effort that will go into completing a story, points. We also use the term velocity to help estimate the number of story points a team believes it can handle in a given sprint. As soon as you introduce terms like these, engineers and managers alike instinctively start to think of them as a way of measuring the value of what is being done.
In fact, points and velocity have absolutely nothing to do with measuring the business value of the work done by the team. They also have no use as a tool for evaluating how hard the team is working, or how much objective work they are getting done. The true value of points is that they represent an abstract and relative metric for estimating what it will take to get one story done compared to another. Ultimately they are intended to help the engineers on the team get better at predicting what will be involved in addressing new stories. But trying to convince managers and engineers of this can be confusing when they see shiny points and graphs that look like they should be going up and to the right.
Read the rest of my article about Points of Confusion in Agile on SitePoint.
]]>One of the greatest advantages of an agile workflow is that it makes time for intentional reflection to encourage constant improvement. The retrospective ritual, traditionally held at the end of a sprint, gives the team a chance to discuss everything that stood out in the previous sprint. This includes looking at what went well and what didn’t, and making course corrections.
But carving out time from a busy production schedule for a retrospective meeting that doesn’t produce features for the product can be a tough sell in a fast-paced and competitive industry. Here are a few possible objections that are worth listening out for, and ways to address them.
Read the rest of my article about Making Agile Retrospectives Productive on SitePoint.
]]>An agile organization needs to embody the philosophy of agile in order to get real value out of the process. Otherwise, agile can become a stand-in for whatever buzzword management technique happens to be popular, and will only serve to obscure any real problems that may exist.
In order to recognize potential agile process issues and address them, it’s helpful to have a set of signals to watch for.
Here are four such signals I’ve noticed–I call them “process smells.”
Read the rest of my article about 4 Warning Signs that Your Team’s Agile Process Stinks on SitePoint.
]]>Agile points seem arbitrary, and it’s hard to see how they can help a team with its real-world concerns, like meeting deadlines.
Hours and days, on the other hand, are easy to understand, measure and weigh against practical external requirements.
Additionally, one of the key rewards that gets teams interested in implementing an agile workflow is the promise that they can learn to accurately estimate the amount of work the team can do in a certain number of days or weeks. Using points seems like taking a step back from that goal.
Read the rest of my article about What’s the Point of Agile Points? on SitePoint.
]]>Traditional waterfall development happens from beginning to end in a sequence that’s easy to understand, and at first glance, agile sprints appear as if they’re simply shorter versions of the same workflow.
There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.
Respecting the differences can help your team–and people watching from outside of your team–get a better understanding of agile and how it works.
Read the rest of my article about Why Agile Sprints Are Not Tiny Waterfalls on SitePoint.
]]>Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.
Here are a few estimation techniques for agile teams that can ease the transition through this phase.
These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.
Read the rest of my article about 3 Powerful Estimation Techniques for Agile Teams on SitePoint.
]]>Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.
A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.
Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.
- Measuring Productivity by Points
Read the rest of my article about Do You Make These 7 Agile Estimation Mistakes? on SitePoint.
]]>The manager is the one person who should be most familiar with what everybody on the team is doing. A manager may appear to be in the best position to oversee the process and evaluate whether or not scrum is being followed. In fact, many of the responsibilities of a scrum master do fall upon management in a more traditional organization.
But there is a basic conflict of interest between the duties of a manager and a scrum master.
Read the rest of my article about Why Managers Make Terrible Scrum Masters on SitePoint.
]]>Agile management has become increasingly popular in the tech world, in part because it addresses some of the special challenges associated with software development, such as rapid release cycles and clear open discussion of complex topics with steep learning curves. Among the most popular agile approaches is a technique called Scrum, which outlines a set of rituals, roles, and artefacts to help a team adopt an agile approach, and track its effectiveness.
One of the rituals that keeps Scrum teams working effectively is the daily standup. A daily standup gives everybody in the team the opportunity to share with the rest of the team, and anyone who cares to listen: what they’ve been working on, what they’re planning to do next, and what ‘blockers’ (or outside obstacles) they may have encountered. Handled consistently, a daily standup doesn’t get in the way of productivity, and increases the transparency of the project, so everybody knows what everybody else is doing.
Read the rest of my article about Is Your Scrum Standup Slowing You Down? on the SitePoint blog.
]]>Engineers and business people alike are enthusiastic about the benefits of creating an agile workplace. Not only is communication improved, and transparency increased, but the ability to produce and iterate on products in a cleaner and more efficient manner can also come out of this work approach.
If you’re considering adopting agile for your work environment for your engineers, it’s important to understand why people would be attracted to this way of working. In many engineering companies, agile is becoming the norm, but it hasn’t been that way forever.
Older approaches such as waterfall development have typically provided engineers up front with complex and detailed product requirement documents, which they then went off and developed in isolation. In an agile environments, product owners and engineers work closely together to refine and develop the features of the product as it is being developed.
Read the rest of my article about Agile Working for Productive Development on the Udemy blog.
]]>