by Dan Williams
Compliance means different things to different people. As I am using the term, compliance is about proving to someone – often an auditor, whether internal or external – that a company is following the processes and procedures that it says it does. These processes are most often put in place to support regulations that constrain the industry segment in which the company operates. In this post, I want to suggest some ways in which Agile methods and perspectives address compliance.
Scrum, a light-weight Agile project management framework, promotes transparency, reporting, and risk mitigation through short iteration delivery of value. Extreme Programing (XP) promotes automated testing, continuous integration, and close-client involvement. By combining these Agile frameworks, "compliance” becomes part of an Agile culture of value delivery.
The following bullets outline an approach to an “Agile Compliance Culture”:
- Identified Compliance Control Objectives become part of the Product Backlog as User Story Acceptance Criteria.
- Control Activities, which are derived from Control Objectives, are automated in testing when possible. An example would be automated logging.
- Automated test suites are run continuously, providing a compliance health check, thus reducing risk.
- Compliance is built up iteratively rather than in a big bang fashion, thus reducing cost.
- Compliance becomes part of the Agile delivery culture.
Compliance is not optional, nor an add-on to standard software development and delivery. Agile values of transparency, risk mitigation, reporting, high customer involvement, and continuous testing readily support a highly-valued compliance software delivery culture.
by Ron Jeffries
Editor’s note: This is a guest post by Ron Jeffries. Ron is the author of Extreme Programming Adventures in C#, the senior author of Extreme Programming Installed, and was the on-site XP coach for the original Extreme Programming project. He has been involved with Extreme Programming for over five years, presenting numerous talks and publishing papers on the topic. He is the proprietor of www.XProgramming.com, a well-known source of XP information. Ron helped create and is a featured instructor for Object Mentor’s popular XP Immersion course. He is a well-known independent consultant in XP and Agile methods.
I often have occasion to describe some very effective ways of doing things. Let me list a few:
- Building software incrementally, in two-week cycles, with each increment showing real working features, is a really good way of managing a project.
- Creating acceptance tests (or checks), which amount to automated examples of what is wanted, is a really good way of ensuring that requirements are understood, and that the software does what’s required.
- Creating developer tests (or checks) incrementally as software is developed, before writing the next few lines of code, is a really good way to produce software that is low in defects, and in which new defects are easily discovered.
- Continuous refactoring can keep code clean without requiring long delays while design is figured out.
None of these things is easy to do: they all require a bit of skill. However, that skill is within the reach of any competent development team.
There are many items that could be on the list above. Essentially they are the elements of good Agile software development practice. There are hundreds of teams, thousands of programmers, who have the skill to do these things, and who do them every day.
Commonly, when I’m teaching a Scrum course or a developer course, or even just chatting with some team, people will raise objections. They couldn’t do this or that, for some reason that they have stuck in their mind.
As it happens, I’ve personally written just about every kind of software that has ever been written, and I’ve worked with teams who have done the rest. There is no kind of software that does not yield to the techniques in Agile, and I’m no more than two degrees of separation from someone who knows exactly how to do it, in the event that I do not.
This means that I am not easily convinced that the objections being raised are valid. I know something that the objecting party does not: I know how to do these things, and they have not yet learned them.
Sooner or later in these discussions, someone will say something to the effect that these ideas are all very well and good, but in the “real world”, they just don’t apply.
You can imagine how impressed I am by this argument, since I have over a half-century of experience creating software by just about every method known, and because I have helped hundreds of people learn how to do these things, and it wasn’t even that hard.
I generally reply to the effect that our job is to create the “real world” and not to imagine that our present situation is the only situation there is. I try to do that respectfully. Sometimes I find that very hard.
So listen up. Agilists like me live in the same real world you do. We’ve done the things you’re doing, we’ve encountered the problems you’re having. We’ve suffered just as you have. And we know some techniques that you probably do not know, and we have found those techniques to be very strong.
You’re free to dismiss these ideas. You might not be wise to do so. But you are free.
Also, get off my lawn.
by Bryan Stallings
Scrum by definition states that there should be one product owner who sets priorities for the team. What do you do when many influencers on your team want to play this role?
by Ron Quartel
"This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration.”
— Ken Schwaber and Jeff Sutherland from the Scrum Guide
The sprint review meeting's purpose is to elicit feedback and foster collaboration. It is an inspect and adapt point in the project. When I hear coaches' and ScrumMasters' theories on what should and shouldn’t happen in this meeting, I like to link them back to the purpose.
Here are some of the common anti-patterns, in my opinion:
1. Anti-pattern: The review meeting is where the product owner gets to see the stories demoed for the first time and signs off on them
You could do that, but I don’t like it. Why? Because the delivery team should have already had the chance to find out if it did not meet “done” before this meeting. Leaving sign-off to this late time in the sprint means there is no time to implement any PO-identified delta, and the team may fail delivery of that story.
I prefer the team to do a demo to the PO in-sprint as soon as it feels it has met "done". This follows the pattern of early feedback that we are trying to foster in Agile. If the PO finds some issues or has minor changes (that will not affect the sprint delivery), then the team has a chance to implement them before the end of the sprint. This pattern keeps the PO involved in the delivery of the increment, and fosters collaboration.
Another reason why I don’t like this is because you run the risk of embarrassing the PO in front of the stakeholders if there are issues with the demo. Having the PO see a demo before the review gives the developers a safe environment to do a dry run, and make sure they know how to demo the story. The PO might even describe how he/she wants it demoed differently or only in part in the upcoming review meeting.
2. Anti-pattern: The only stories demoed are the ones that are done
The Scrum Guide says that in this meeting: “The development team demonstrates the work that has been done... The Product Owner explains what Product Backlog items have been ‘Done’ and what has not been ‘Done’”. So, do you show work that has not been “done”? I think the answer to that is up to the PO. If he/she sees value in the work that was done and can see that there is enough done to get feedback, then why not go ahead and show it? Yes, you will mention that it is not as complete as hoped at that juncture, and point out what made it “not done”. Remember, the purpose of the meeting is to get feedback, so if there is enough to get feedback on, show it.
Here is an example: I had a team that deployed software to an embedded system. Part of “done” was deploying the software to a test workbench. Come review day, the one test harness the team had died. The only way to demo was in an emulator. Is that the right thing to do? Yes. You explain to the stakeholders why it is not in the workbench, and will have to resort to showing the progress of the increment in an emulator in order to continue with the meeting. You want feedback and this will get you feedback, so yes, that is the correct thing to do.
3. Anti-pattern: The demo is for the team to see what work has been done
While this might be true, I don’t think it is the primary purpose of the meeting, and not one of the goals. The primary purpose is to elicit feedback from the stakeholders and/or customer(s). A highly collaborative team should know what is going on with the rest of the team during the sprint, anyway. Particularly, if team members are co-located, and even more so if they are pair programming (two practices I cannot recommend enough). I prefer that the entire team watch the sign-off demo to the PO mid-sprint. This might look like, for instance, a pair in a team calling a huddle, and calling the PO to view the work it feels is “done”. The team gathers around and watches the pair explain the finished work to the PO, and are present to hear any feedback or needed changes which might get added to the sprint backlog.
4. Anti-pattern: All stories must be demoed
I feel the demo should be slick, exciting and engaging to the stakeholders. Not all stories are necessary to demo to a room of stakeholders and customers. There may be stories that are run in a sprint that, while necessary to the forward momentum of the product, don't immediately show value to stakeholders. In these cases, I feel a demo can do more trouble than good. Yes, you should mention that work was done, but that is enough for these stories. For example, let's say you have to change the format of the log output so that it can be consumed by the new data mining platform that another project has implemented in the company. You can see how this feature is important -- but in a product that is going to be a user-facing application is this feature an overhead story, or really an end user feature story?
Under these circumstances, I would recommend not wasting time and energy with demoing these types of stories. Remember, you are looking for feedback. Show only the stories that will elicit feedback. Don’t waste people's time. If you can get through the meeting in under the allotted time box, then great!
5. Anti-pattern: The whole team must attend the review meeting always
"What?!" I hear you say. Now, I think that ideally yes, the whole team should participate. But if the room that you have available for the review is too small to accommodate the whole team and all the stakeholders involved, then I would recommend only bringing as many of the delivery team that the room will accommodate. At a minimum you (as PO) should bring the members needed to run the demo if you are unable to do it yourself.
6. Anti-pattern: The overall project progress is not discussed
From the Scrum Guide: “The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date.” Too many “demo meetings” I have attended are just that -- demos and nothing else. The meeting is a sprint review meeting of which a demo is just part of the meeting. The important aspect of discussing the remaining backlog is missed, all too often. My personal preference is to bring in a product burn up chart. It’s simple to maintain, and contains the smallest (and most useful) amount of information needed to portray this information. And make it big! Agile likes big and visible and transparent.
Start with the "why"
When you understand the "why", it will help you make the best decisions around any of the Agile practices. I hope these scenarios have helped you get a better grasp of the purpose behind the sprint review meeting.
by Pam Dyer
As many of you know, Laszlo Szalvay recently joined SolutionsIQ as a vice president. He co-founded the Scrum product and services company Danube that was acquired by CollabNet in 2010, and came to SolutionsIQ after leading CollabNet’s international Scrum business line. He is a successful entrepreneur within the Agile software development industry with a focus on growing businesses. He is a frequent speaker at industry conferences, a contributor to key industry publications, and a vocal advocate for Agile-based methods and -- in particular, the Scrum framework.
Laszlo was recently interviewed by Kane Mar, a Scrum trainer (CST) and coach (CSC) who authors the popular Scrumology blog. Kane and Laszlo worked together for three years at Danube, where Kane coached clients such as QPass, Microsoft, Capital One, Progressive, and TransCanada Pipelines. Kane helps companies create software and products that matter and users are passionate about.
Watch this interesting interview to learn how Laszlo came to the Agile community and what brought him to SolutionsIQ. He also describes how he helped develop ScrumWorks, an Agile project management tool that created a huge lead generation engine for Danube. As a result of the tool's introduction, he was able to land the first-ever government Scrum project in 2004 -- the first time the term "Scrum" was used in a government RFP. You'll also learn what they both think about future of Agile and Scrum.
by Daniel Gullo
Story Points are a relative estimating method -- one item is compared to another on the Product Backlog. Money is an absolute or precise measurement, as is time. Humans do better with relative estimating methods than with precise estimation methods.
by Dave Wylie
There is a lot of buzz around continuous delivery. When does Scrum, with iterative releases, compare to CD, and when should each be used?