Does Scrum prohibit job titles?

No.

Although Scrum does not recognize any titles defined outside the Scrum Framework, titles are almost always present in the organization. While Scrum doesn’t recognize titles other than “team member”, making changes to pay and rank structures within your company is a cultural norm set outside Scrum in most cases. For example, my title at Scrum.org is Chief Craftsman. That doesn’t mean I will never test something my team is working on, or work outside the context of my business card. Of course I will, but it would be somewhat awkward for me to hand a business card to someone if it read “David Starr – Development Team Member”.

Practical application of Scrum means we must be aware there are specialties present on any given team. Might one Development Team member have deeper skills in test, or UI design than another? Of course! To deny this would be foolish, but Scrum doesn’t dictate the titles these people put on their business cards.

Scrum’s reputation for eschewing job titles evolved because Scrum focuses on building cross-functional and self-organizing teams. When these teams are successful, titles just don’t matter and team members teach each other about the specialty jobs over time. The Development Team is held to account as a group and therefore titles are irrelevant within the context of Scrum. Good Scrum Teams will naturally care less about titles and more about results.

Some companies have experimented with a general lack of job titles and found that to be a good thing for their culture. Scrum is 100% compatible and encouraging of this, but the implications of such a system go far beyond the borders of the Scrum Team. If you truly want a company with no job titles, applying Scrum will be one of the less challenging things you’ll learn to do.

Traditional management practices, such as having a clear career path, are still used extensively in companies very successful with the Scrum Framework.

Scrum doesn’t hate titles. It just ignores them.

Scrum.org wants to be a valued resource for those practicing agile development methods and techniques, regardless of what those methods and techniques are called. Accordingly, we just announced our new webcast series, “An ongoing public discourse on Agile, Scrum, and professional software development.”

Our plan is to keep these free to attend and to ensure previously recorded episodes are available for viewing. Topics will range on all subjects professional software development related, and will occasionally even discuss Scrum. Anyone may present, but we won’t allow any “you should buy this product because it will make you more agile” crap.

We are leading off the series with Chad Albrecht’s Agile Economics, the Dollars and Sense of Scrum. I’ve seen this talk from Chad, which is why I asked him to do it on the webcast. If you need ammunition for convincing your executives (or even just your boss) about the legitimacy of agile methods, come see this talk. You’ll get an arsenal of arguments and case law to support the idea that this whole agile thing is good business. You may register to attend this episode, but we only have 100 seats available, so space is limited in the live session.

If you have suggestions for topics you would like to see covered, or if you have an idea you would like to share as a presenter, please let me know. We want hard-core geek topics as well as topics of interest to process wonks.

Quote 1

Building a system using a well modularized, top-down approach requires that the problem and its solution be well understood. Even if the implementers have previously undertaken a similar project, it is still difficult to achieve a good design for a new system on the first try.

Quote 2

… start with a simple initial implementation of a subset of the problem and iteratively enhance existing versions until the full system is implemented. At each step of the process, not only extensions but also design modifications can be made. In fact, each step can make use of stepwise refinement in a more effective way as the system becomes better understood through the iterative process. As these iterations converge to the full solution, fewer and fewer modifications need be made. "Iterative enhancement" represents a practical means of applying stepwise refinement.

Quote 3

Each iterative step consists of selecting and removing the next task from the list, designing the implementation for the selected task (the design phase), coding and debugging the implementation of the task (the implementation phase), performing an analysis of the existing partial implementation developed at this step of the iteration (the analysis phase), and updating the project control list as a result of this analysis. The process is iterated until the project control list is empty, i.e., until a final implementation is developed that meets the project specifications.

Why I am Quoting this Guy

I splurged with an Amazon gift card I got for Christmas and bought a printed version of Foundations of Empirical Software Engineering, The Legacy of Victor R. Basili. You can get the PDF here. The article on Iterative Enhancement is on page 28.

Professor Basili’s observations make even more sense in light of the project he was talking about, his implementation of a programming language. Can you think of a better problem domain for incremental releases? As soon as I have a new language feature, I want to use it in the definition of yet another feature. Beauty personified.

The Kicker

When you note the pub date on these papers, you’ll see that it was published in 1975. I was 5 years old.

Giving birth to Agility and parenting it to pre-pubescence was a miraculous feat. The thought leaders who brought us the manifesto and subsequent culture shift deserve our thanks for seeing the need and creating the right message at the right time. Thanks to these revolutionaries Agile is not a footnote, but the most promising path forward to improving our profession.

One focus of the last 10 years of agile discussion has been, “There are better ways to develop software.” While the state of spaghetti code in the universe is still a big problem, progress has been made in this area. It is no longer radical to think in terms of test-first, pattern-based, or *-driven. Many teams are just acting more professionally, and that’s a wonderful thing.

The other primary focus of the last 10 years has been teaching technologists to actually speak human. You know, with emotion and stuff. And there’s great news; as a profession, we developers aren’t as jerky now as we were 10 years ago. See? It’s working.

The Agile Consensus

I get to see many implementations of Agile Software Development. Not surprisingly, most teams out there aren’t living the dream, but are actively trying to improve. Indeed, recent studies and surveys have noted that projects using Agile methods now outnumber plan-driven, or waterfall, projects.

Sam Guckenheimer calls this change the Agile Consensus in his recent book with Neno Loje (disclosure: I was a technical reviewer on this book). The idea behind the Agile Consensus is simply this: Agile won. Creating software with plan-driven techniques obviously falls short of the advantages of developing with a focus on humanity and exploiting shorter feedback cycles.

Bottom line: Agility has crossed the chasm and is no longer only the domain of developers. The enterprise wants big-A Agility.

Not Crazy Anymore

Whether or not a given practice is crazy or “edgy” depends on who you talk to. Organizational acceptance of a given practice is typically rooted in the values that practice supports, and the practices here seem to have reached a level of general acceptance in our industry. Mostly.

Daily Team Meeting

Whether you call it the Daily Scrum, the Daily Standup, or simply a daily team meeting, the practice of a quick, informal team meeting held at the same time and place each day has really caught on. The reason for this is simple; when done well, the daily team meeting helps teams be more productive and improves situational awareness in complex environments. And regardless of what kind of software development you do, odds are it is fairly complex.

The daily team meeting is one of the most misunderstood and poorly executed practices mentioned in this article, but I digress.

Bottom Line: Daily Team Meetings are commonplace and useful. They aren’t considered crazy by most teams anymore.

Sprints

Sprints, or iterations, are simply short periods of dedicated time within which teams will deliver working software. These time boxes in which teams agree to deliver something have changed the way we think about long, death march projects. Many teams know that progressing toward the broader goal of releasing software is often best managed by delivering working software all the way through a delivery pipeline, with increasing amounts of functionality each time.

Businesses leaders often love Sprints because Sprints are an obvious way to manage risk. More on this later.

Bottom line: While there are other ways to organize work, doing it in small batches within a Sprint of 30 days or less is a model that has proven itself time and again.

Test as We Develop

Lean thinking encourages “testing at the point of work”, which is a broad concept we’ve apply to software development to derive TDD, BDD, ATDD, and other forms of simply proving that software works as we create it. We’ve learned along the way that we don’t even need to think of this as a verification process. Test-First practices have proven to not only help developers build the “right” software, but to build the right software well.

Not every developer has drunk this Koolaid, but most understand the basic value behind Test-First as either a design tool or a verification tool. Those of us who really drank deeply see Test-First development as the de facto way to write code. Sure, I’ll bang out a quick shell script without an accompanying automated test harness, but that’s a simple fit-for-purpose decision.

Bottom line: When making software that needs to be work right and be crafted well, many developers see Test-First practices as indispensable.

Deliver Frequently

Delivering working software frequently allows development teams to actually deliver something, and that’s half the battle. Frequent delivery of working software enables the most valuable feedback loop in software development. The conversation around this feedback loop is simple and sounds like this:

“Here’s what we made. Here is how it works. What do you think?”

And then comes the tricky part – Actually listening to the response. This helps teams build the right thing next. I loved watching eBay a few years back as it changed its color scheme and skin layout gradually over a few months. They design a destination look and feel and migrated to it with frequent delivery of small changes in their UI. This allowed the product to evolve, rather than re-release. This is how software delivery is evolving and the most extreme form is called “Continuous Delivery.”

Delivering frequently may sound a lot like “Sprints”, but there is more going on here. Sprints are simply a forcing function for frequent delivery. There are other ways to pull it off. Frequent delivery all the way to customer feedback can change the way a company engages its customers and plans its strategic moves.

Bottom line: Frequent delivery is craved by executives for the business advantages offered and by technical teams because it makes actually shipping ubiquitous.

Still Crazy

While some Agile practices have crossed into “just plain old good ideas,” many are still seen as edgy, or extreme. Despite evidence that these practices offer real value and better alternatives to traditional thinking, the old ways of looking at the world are just so ingrained that these practices provide fodder to skeptics.

Pairing

No technical practice has drawn more fire than Pair Programming. Hard data has begun to emerge about the practice of pairing, and all that data shows (to varying degrees) how pairing creates higher quality and simply better software. A paper

There are also a ton of human advantages, like increased learning, knowledge sharing, and removing single points of failure within a team.

Why then has formal pairing been relegated to the domain of roman sandal wearing hippie agilistas? Most development team leaders or managers simply see pairing as an investment of two people doing what one could accomplish. I won’t try and convince you otherwise in this article, but I will mention this:

Barry Bohm has made a very distinguished career of studying software development. In Balancing Agility and Discipline, he asserts that 60% of all software defects in production could have been caught with a peer review. Pair programming is continuous peer review. You do the math.

Finally, most developers treasure their alone-time with the code. Sharing the way I approach problems or write code can feel like a job interview every day. That kind of scrutiny can feel very uncomfortable unless I am in an environment of absolute trust. That ties the success of this technical practice to the culture of the team and company.

Bottom line: Pair programming is still seen as eXtreme, and the transparency it forces can terrify many developers.

Funding Alternatives

Companies spend a lot of time and energy developing golden plans for the next year. Strategic planning is a dependable activity of middle-management in those months counting down to the end of the current fiscal year.

We know good and well that we can’t predict the evolution of a software project beyond a few months in most thriving businesses. Change just happens. Why then do we persist in thinking Big Funding Up Front is any different than Big Design Up Front? Some are making inroads with models of T&M funding, fixed cost, adjustable scope, and other techniques like incremental funding. However, for the most part we remain stuck in annual funding models because business Agility, the real promise of Agile, remains elusive.

Bottom line: Software development projects are still funded when we know the least about how we’ll be spending that money.

Strategic Iteration

While Sprints, or iterations, are very popular on the operations side of the house, few companies see them as the strategic advantage they really are. Sprints are loved by the business because they reduce risk, but actually refining the scope, plans, and functionality based on an iterative feedback model is a foreign idea. Iterative delivery provides a regular cadence that can be interpreted as “milestones” by traditionally trained most project managers.

The innovation companies could have with regular Sprints is lost because of the aforementioned Big Up Front Funding that causes Sprints to be seen as a tool of operations.

Bottom line: The potential value of iterative incremental teams is being wasted by a determination to fund fixed-scope projects up front.

The Next Challenge

Professionalism

The profession of software development is reflecting upon itself right now and the question of what it means to be a software professional is coming to a head. The craftsmanship movement has a genuine toehold with many introspective developers; Universities are actively looking beyond computer science programs to fill the supply void of industry; and my mom thinks she’s “writing code” when her excel macro runs without error.

Writing solid code is now table stakes for being a software professional. The expectations we have of true professionals are becoming appropriately greater. As technology matures and abstractions go higher, the productivity of development teams should be through the roof. Yet, it isn’t necessarily the case and hiring organizations are desperate for some way to assess prospective developers en masse.

One desperate attempt at identifying professionals is the ridiculous history of Scrum certification. Certification teases with the allure of simply trusting a credential. Unfortunately, this isn’t working for any known certification yet, university, private, or otherwise.

Bottom line: Professionalism in software is finally being demanded by those creating it, and by those asking for it.

Maturity

Just like the allure of hiring a professional, the temptation of the perfect development process is just too tempting for the ignorant to ignore. The success of simple frameworks like Scrum and Kanban provide just enough structure to get things done, without providing prescribing specific practices. That scares plan-driven organizations that value control over creativity.

To get real traction with Agile methods means getting not just permission, but support; and support means money. Before bureaucracies spend money, they want assurances and guarantees. False ones will do; look at how well RUP and MSF sold.

Providing any compelling story for change requires supporting data. The willingness of good leaders to instigate and support true change will start with the end in mind. While the end state of an Agile transition can’t be predicted, case studies and measurements of established Agile teams are the catalysts for getting Agile transitions started.

The demand for reassurance will drive development of tools like assessments, maturity models, and formal adoption programs. As older and more established industries explore Agile, these tools will be in heavy demand by those wanting to make data-driven decisions.

Bottom line: Agility is moving into more mature organizations and Agile itself will need more accessories of maturity.

As is the case with most children, 3 of my 4 kids are basically sociopaths. Although this is improving as they age, the kids are often unable to consider the feelings and positions of others. In short, they lack empathy. One might even propose that gaining empathy is a major part of growing up.

But I digress…

Given this state of affairs, hearing things like, “That’s not my job,” has been pretty common.

Grrrrrr.

As someone who focuses a lot on self-organizing and cross-functional teams, this makes me want to scream. Of course, we can’t fire the children, so I instead encourage them to tweak the family method and help me find ways we can work as a team instead of as a loose collection of self-interested individuals.

You can imagine my delight when after 7 years of pursuing collective accountability for the kids I recently heard the following conversation between M, my 15-year-old, and C, my 13-year-old.

C: What are you doing?

M: Doing the dishes and cleaning the kitchen.

C: Can I help you?

M: Sure, can you wipe the counters?

I felt like this.

Each week, our family has a Family Meeting in which we inspect and adapt how we work together and the family method itself. We also use a board to visualize and manage work for chores and things.

The board undergoes frequent change as does the process we use. Our current board reflects these principles:

• The work needed each day doesn’t change that much.
• All work is negotiable with mom and dad. Maybe the floors don’t need to be vacuumed today (but they probably do ).
• The available work force to accomplish this work changes a lot, based on the realities of kid scheduling.
• The work needs to be done, regardless of who is available to do the work.

The rules of using the board are posted on the wall under the board itself. They are:

• Only mom or dad may move an item into the parking lot (don’t do this today)
• Each person may have no more than one item in process at a time.
• You are not done with a chore until the work has been reviewed by a sibling or parent.
• No one is done until all work is done.
• The nightly standup meeting may not occur until everyone is done.
• No one may go to bed until the nightly standup meeting is done.
• You must do 2 pushups for every minute late to bed.

This magic combination of rules supporting the above principles coupled with the board below resulted in the notion of group accountability.

Finally.

I may have indeed found it. Time will tell.

I would love to say Scrum is truly adherent to OCP (Open Close Principle), but the truth is we are always learning more about the practice of Scrum. Smart people find new ways of enacting Scrum’s values and principles. This means that on occasion, Scrum itself may change to support this learning. Ironically, this usually means Scrum becomes less prescriptive, and that is exactly what happened in this summer’s 2011 release of the Scrum Guide, which loosened some of the specific practices prescribed by Scrum.

James Coplien and I were asked by Ken and Jeff to act as aggregators for community proposals to extend and modify Scrum. James and I have created a model we hope provides enough formality that proposals are necessarily thoughtful, yet enough flexibility that good ideas are easily explained. The links at the bottom of this article will take you to pages that explain the process we designed.

In collaboration with Ken and Jeff, we will steward these proposals as they are provided. We are very excited to see how Scrum is being used!

We expect to see more proposals for extension than modification, and I encourage you to submit your own. If your team has extended Scrum with complimentary practices that do not violate the integrity of Scrum as defined in the Scrum Guide, tell us about it.

Scrum Guide Links

• Read It
• Change It
• Extend It

We want to be sure that our software will be delivered on time, that it has no known defects, and that it works as the customer wants. We want to be sure that the feature we committed to completing by Friday gets done, that all the tests will pass, and that we are done in time to go home for dinner.

That’s a lot to want.

When complexity is high, as it so often is in software development, is it really reasonable to insist upon the certainty that we so desperately crave? I heard some politicians on the radio asserting that, “Americans want to be certain that their taxes won’t go up, that their jobs won’t go away, and that their homes won’t be foreclosed upon.” He further stated that it was the job of congress to provide this certainty.

Well, tough.

And we all know it.

We simply can’t depend on these things, as so many variables are outside of our control. Just like congress trying to pass some legislation to increase certainty, software development teams try to control variables in our development processes to increase certainty with varying degrees of success. The good news is that I finally found a profession that lies more about certainty than software developers (although I suppose most politicians learned that behavior while working as attorneys).

Thus:

• Politicians understand that humans want certainty, so they pretend they can provide it.
• Software development teams understand that humans want certainty, so we pretend we can provide it.

You know how you roll your eyes when you hear some jackass politician make promises we all know he or she can’t keep? That’s how customers have felt about us software folks for years, too.

Yep, drink it in!

And that extra time you spent adding a cool new technology that wasn’t really needed or wanted? That’s pork-barrel spending .

So, you know what the Agile Manifesto really was? It was an apology that we’d been lying and producing crap while acting like a-holes for the first 60 years of software development. Stop being so surprised that it is taking time to get our constituents to trust us again. You wouldn’t trust us if you weren’t one of us, either.

The good news is software development isn’t in nearly as bad a shape as congress .

Cheers, and have a good day.

Jeffrey Palermo joins us to talk about his career and the new challenges of leadership in a technical organization. That inevitable moment of choosing whether or not to work in management deserves serious consideration and Jeffrey helps us think through the issues any potential technical leader faces.

Jeffrey is the Chief Operating Officer of Headspring, a custom software development firm in Austin, TX. Jeffrey has helped build the practice from a humble core group to a multi-million dollar operation recognized on the Austin Fast 50 list and the Inc 500. Having studied and observed software history, trends, fads, and the constant pendulum swing that is the technology industry, Jeffrey prefers a "no surprises" approach to serving clients by providing the right solution to their unique problem.  He is a six- time recipient of the  “Microsoft Most Valuable Professional” (MVP) award and has spoken and facilitated at industry conferences such as VSLive, DevTeach, the Microsoft MVP Summit, and Microsoft Tech Ed. He also speaks to user groups around the country as part of the INETA Speakers’ Bureau. A graduate of Texas A&M University, an Eagle Scout, and an Iraq war veteran, Jeffrey holds his share of certifications, has published many magazine articles, and has written two books. He is currently earning his MBA from the Jack Welch Management Institute.

Jeffrey is an author of a recent book, ASP.NET MVC in Action.  You can obtain the book at http://bit.ly/aspnetmvc2inaction.

Show Links

• Jeffrey’s Blog
• Professional Services Metrics Dashboard
• Headspring
• @jeffreypalermo
• Headspring Labs BitBucket

Crazy though this may sound, this particular niche has really starting showing up in my life a lot lately.  Anyone else applying agile methods learned at work to home life?

In this episode, Matt Milner substitutes as host an interviews me about MSBuild. MSBuild, you say!? Why yes, that amazingly high tech tool of automation. Yes, this is truly the stuff of Jedi’s. Maybe not, but if you don’t know this tech already, you should. MSBuild is one of those things that .NET developers need to have in their toolbox.

David Starr is a technical instructor with Pluralsight where he focuses on the Visual Studio ALM platform, Agile Software Development, and patterns and practices in .NET. He is a trainer and author with Scrum.org, a Microsoft Visual Studio ALM MVP, the founder of ElegantCode.com, and host of the Pluralcast podcast. He enjoys re-kindling the passion in developers that attracted them to the software development craft.

Links

• MSBuild on MSDN
• David’s MSBuild course in Pluralsight on Demand!
• MSBuild Team Blog
• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build (Book)
• David’s Blog
• MSBuild Extension Pack