Great ideas about JavaScript practice

When you find a good resource like Clean Code JavaScript, please join me in spreading the word. (You can do it here, if you want, but do it somewhere!)

JavaScript programmers: I recommend you consider every idea here and implement those best for you and your projects. There’s a difference between a cook and someone using a cookbook. Your evaluation of a list like this makes you more valuable. Effective implementation of applicable ideas makes your code more valuable.

const: JavaScript ES6 best practice

Summary

The audience for this article is JavaScript programmers. Intermediate programmers are likely to have seen the ES5 information before. The ES6 (ES2015) information might be new to them.

In the JavaScript ES6 world, a growing number of programmers are converting from declaring variables with ES5 “var” to ES6 “const” and “let”. Perhaps unexpectedly, some of them are advocating using “const” for every variable they plan to leave constant during its life. (Those radicals! Only …) I’m joining them.

Note

Some readers may consider this post a large departure from my prior posts. This is not an example of project management content. I expect some future posts to be about PM and some to be about programming. This one is about JavaScript programming. I’ll use tags to separate them.

Detail

definition: In computer code, a problem is a condition that is troublesome enough to change. A near-synonym: bug.

This ES5 JavaScript includes a number of improvable conditions.

var startUSCivilWar = 1861
function example () {

… // More code here.
startUSCivilWar = 1961

// Changing history?

console.log(“The ” + warName +
” started in ” + startUSCivilWar +
“.”)

// Uses the warName declared
// later because of hoisting.

… // More code.
var warName = “U.S. Civil War”

}

Condition 1: Our code declared a variable (startUSCivilWar) outside all functions, so it’s a global variable in the computer environment. Everyone sharing the environment has access to it. Had we happened to use a variable name JavaScript already used, the JavaScript variable is unavailable to us and everyone else using the environment. Suppose we chose a variable name like “Object” or “Array”? (Please don’t do either of those in a production environment! 🙂 ) Ick.

Condition 2: Our code changed startUSCivilWar, which is probably bad; it might not be intentional. It’d be great if the interpreter could help us find the condition.

Condition 3: Our code used a variable warName not declared at time of use. Would you agree that it’s at least ambiguous (maybe even questionable) whether the programmer intended this value for this log statement? Lots of programmers with code like this later consider the code to have a bug (or a problem). Can the interpreter help?

Here comes ES6 with some new options.

const declares a variable whose value the interpreter won’t change.

Both const and let declare a variable that cannot be used before its declaration. The variable is still hoisted; the area where it can’t be used is its “temporal dead zone”. (Fancy term, huh?! Sounds terrible.) See discussion in [Zakas 2016] or elsewhere.

const and let variables declared outside all functions are available globally, but aren’t global variables. The earlier “Object” and “Array” examples would thus block use of those JavaScript variables in your code, but not in others’ code. I say: That’s better.

The same ES6 code might look like (underlines indicate changes):

const startUSCivilWar = 1861
function example () {

… // More code here.
startUSCivilWar = 1961

// Error. Changing a constant.

console.log(“The ” + warName +
” started in ” + startUSCivilWar +
“.”)

// Error. Undeclared
// variable: warName. The
// later one isn’t usable
// until declared.

… // More code.
var warName = “U.S. Civil War”

}

Variable startUSCivilWar is available everywhere in your program, but it is not a global variable.

The interpreter threw a couple errors, each of which give you a chance to change a condition before they’re problems. Further, it flags them during development, before your boss or client sees them in execution. Low cost; high benefit. That’s an easy decision.

Personal experience with const and let: I find that I know at declaration time whether I intend to change the variable value. Using const or let accordingly is an easy habit for me.

Roughly half of my variables are constants. I presume that’ll change with the types of programs I write.

Due credit: I didn’t come up with this. I got it from [Zakas 2016], page 12. I presume lots of other places on the web recommend it. I join them.

Source Mentioned

[Zakas 2016] Nicholas C. Zakas. UNDERSTANDING ECMASCIPT 6. No Starch Press. San Francisco, 2016. ISBN 978-1-59327-757-4. Also here on the web, accessed Wed Oct 19, 2016.

Entrepreneurial Spirit

What can a person do to make a difference in the world?

Lots of people I respect feel we need more entrepreneurs in our economy. Even … in the world economy. I’m with them. Look for problems no one else sees. Solve them. Sell the solution.

Recognize that good ideas have a shelf life. Be attuned to the time an idea goes stale; have another ready to develop. In your work life, be ready to move with the times.

By way of example: I started a company. It’s not a big deal. A lawyer and an accountant gave me advice on the legal structure I should adopt; I’ve received significant benefit from the investment. I’ve always admitted to anyone who asks that I’m not much the sales guy. It has always nagged at me: “If you don’t have all the parts of a company (marketing, sales, products, distribution, etc.), are you really a company?”

Another side of me always argued, “Doesn’t matter. You’re running your company. It doesn’t have to look like any other company in the world. Besides, for the product you’re selling, how would you effectively and cost-effectively market and sell?” Having no answer to that latter question, this side always won my internal debate.

I have since gotten some experience with “freelancing” on Elance.com. (Don’t follow me there; Upwork.com bought them and is consolidating their businesses to Upwork. If you’re interested, see Upwork.)

Here, it is pretty apparent how to market, sell, and do all other parts of the business cycle. And it is apparent that many actors are concentrating on small parts of the total and staying around. Hmmm … I think that spells opportunity. If I can do the whole package, I might have all the work I want. Cool!

If I go that direction, things will be very different.

Talk about competition! People from all over the world are offering jobs and bidding on jobs. I did a small job for a guy in Ohio. I competed for his attention with people from everywhere. I’m thankful he offered me the job. We did his work by collaboration over the web. He could have been anywhere. (In point of fact, he was on the road the whole time we worked.)

I could find myself working for firms in Bosnia, Egypt, China, India, Brazil, Europe, Canada, or the U.S. And all from the comfort of my home. With no commute! Sounds tempting!

I think you’ll see some changes on my web site and life in the coming months. I’m busy preparing. I’m still the same me. I intend to continue working in information technology. Otherwise, I have all options open. Maybe I’ll go back into office work and commuting again. Maybe I’ll work from home and all over the world at the same time!

Keep your options open. Be entrepreneurial! Do what you love to do.

All comment welcome! You don’t have to sign up to leave a comment. You don’t have to identify yourself. Of course, I don’t have to allow your comment on this blog. Lots of comments come in; most are thinly veiled attempts to market something to readers here. You never see those comments.

Some Hints About Managing Time

(I had reason outside this blog to write this. It may not be at the center of interest for this blog, but I’ll include it here in case it helps someone!)

Good process makes time management lots easier and less stressful.

List The Big Goals  It’s great to always know the three most important goals for the coming months. You might find the exercise of writing them to be difficult! Try it! Maybe you don’t need three; maybe you need more. Find a number that works for you, but don’t try to work with seventeen “most important goals”; that’s too many.

Make a To Do List  In my personal life, I’ve experienced a certain feeling of being constantly behind and stressed; it’s tough! The antidote is: Write it all down. Every time I’ve felt that feeling, I’ve also felt I should have recognized it earlier. Every time I’ve created a list of all the things to do, I’ve emotionally reacted to the full list with relief, “This isn’t that tough!”

Your list has all your assignments and due dates on it. Feel free to put other things on the list; they may deserve part of your time, too.

Prioritize Your To Do List  Sort your list by importance, which for me changes with due dates and with my Big Goals; you may have other factors. The ability to sort the list is valuable; consider writing the list items on index cards or in an electronic file so that sorting is easy for you. (In this case, “easy” includes “quick”; don’t spend a lot of time maintaining your To Do list!)

Break Big Items Into a Series of Smaller Items  Perhaps a first task for a major project is research. Set yourself a date by which you’ll complete that research. You’ll may want to get more sources as part of later work (making the task not fully complete), but getting most of the research done early makes the rest of the project smaller. Further, it’s easier to prioritize the research with other current priorities when it is separate from the larger project.

Look at the Top Several Items  Often, you’ll see interaction: “The only way I’ll complete this number 4 item in two weeks is to defer this number 3 item for a while.” Let your Big Goals drive such tradeoffs; focus your limited time.

Execute The Plan  Every part of every day, work on the most important item on your list for that moment. Work each item thoroughly and to reasonable completion, but don’t spend excessive time. There’s a balance here; there’s other work to do. Leave the right amount of time for fun and family (especially if you didn’t include activities with them on your To Do List!)

Schedule Fixed Time  Big Goals may deserve scheduled blocks of time. Reserve your work time. (Income is good!) If you’ve committed to an organization (say, a church choir), reserve the time they need. If every Tuesday evening (only an example), you work on Big Goal #1, it gets to be a habit and it’s easier to complete that goal. Don’t schedule your whole week; you need some flexibility. Are you over-committed? If so, the best time to say “No; I can’t do this.” is early rather than late!

Stick to Your Plan  You’ll probably feel, “Is it worth it? Really? Spending time surfing the ‘Net is so much fun!” Yes … it is. That’s just an example of conflict you might find with this process. It’s a matter of balance. Are the choices you’re making entirely consistent with your Big Goals? That’s your call! Do your Big Goals need change?

That’s a good process for managing your time. There’s lots of flexibility in it; if changes to it work better for you, who better to decide to use them? Good luck!

Upcoming Events of Note

I need to be more regular about posting messages here about upcoming events. (Okay … I need to be more regular about posting messages here period. That’s another issue!) Two coming events deserve announcement here.

Policy: I intend announcements like this to be a service to readers. No one approached me to post these notices; I don’t expect to receive anything in return. (Though … it’d be nice to earn a reader or two!) I hope this helps you.

Omaha Agile Development
“A Walk Down the Agile Coach Development Path – Lyssa Adkins & Michael Spayd”
Tue Mar 19, 2013 5:30 PM
March 2013 Omaha Agile Development Group
free; some of these events include food

Lyssa is author of “Coaching Agile Teams”, part of the now-familiar (to readers of many Agile books) “Addison Wesley Signature Series”, this one with forwards by both Mike Cohn and Jim Highsmith. Lyssa and Michael are Co-Founders and Co-Presidents of the Agile Coaching Institute. At one point, there were 110 people signed up for this event. Come see your agile peers!

UNO IT Professional Academy
numerous seminar subjects
Thu Apr 4 and Fri Apr 5, 2013
UNO Peter Kiewit Institute
UNO IT Professional Academy
registration instructions at above site

I wrote about the October version of this event at Good Renewal Experience. Both presentations I saw in October are offered again.

Perhaps I’ll attend one or both of these and write a summary of my experience, much like Good Renewal Experience and Agile Myths and Ideologies Meet the Scaled Agile Framework. And perhaps someone else will attend and post their summary here! I’ll welcome other submissions; I don’t guarantee inclusion here, but it’d be great to include such work here!

Agile Myths and Ideologies Meet the Scaled Agile Framework

I spent a thoroughly stimulating evening last week at a meeting of the Omaha Agile Development group. I have recommended their meetings before; that recommendation stands. They’re doing valuable and important work serving the Omaha business community and its members.

CSG International, with operations here in Omaha, decided some years ago to increase their agility. Last week, author Dean Leffingwell consulted with them in Omaha, intending to help them identify good next steps and to help them more sharply focus their end goal. (Experience seems to show that such assistance from highly qualified advisors is an indicator of succeeding in and of speeding such transitions. But you may not find that advice offered by a consultant to be entirely unbiased! (grin)) As long as Dean was in town …

Omaha Agile Development learned of Dean’s upcoming visit and invited him to speak to us. CSG opened its new facility near Dodge and 180th (two big, beautiful buildings, judging by what I saw). Something like 70 people attended. I am thankful to all involved. Well done.

I knew of Dean from having read his book Scaling Software Agility: Best Practices for Large Enterprises (ISBN 0-321-45819-2) on recommendation of a member of Omaha Agile Development. I, too, recommend the book. The earliest agile books concentrated their advice on small teams; this book is among those extending agile advice to “scale” (to collections of teams and potentially to large groups of contributors).

I used the title of Dean’s presentation for the title of this post: Agile Myths and Ideologies Meet the Scaled Agile Framework. Below, I share some of what I took from his presentation, along with (a little) background. This post is undoubtedly not a complete record of what he said.

Dean observed that at the time of Royce’s waterfall paper, waterfall was better than other alternatives available and he supports the industry decision then to use waterfall more. Had we known then what we know now about waterfall, agile, and technology development, we might well have best moved differently. We didn’t know that material; our work with waterfall and new technologies has educated us well. Agile is good guidance for change now. If we knew now what we’ll be saying about agile in 20 or 50 years, we might move differently now. Dean says he doesn’t know what we’ll be saying, so he advocates moving to agile. Our experience with agile will inform future changes.

This paragraph is background from me: I have observed some bias among agile writers to give voice almost exclusively to well-developed aspects of agile. (I exclude from consideration statements of “religion war” fervor we sometimes hear among agilists, like “<Their method> is only for people who can’t figure out <my method, the right method>.”) A blog appropriately titled, Is It Blasphemous To Criticize Agile, is well worded, shapes the issue well, and points to valuable other reading. On that subject …

Dean gives voice to both well- and under-developed aspects of agile. My opinion: he does it respectfully and in pursuit of finding a better way for all of us. His balance is refreshing.

He talked about his writing. These days, he says, most of his writing time goes to constant updates of his web site. It’s a rich set of material. It must be a key basis of his consulting practice. It’s free (the web site is free; probably not the consulting (snicker)). He calls the process he advocates “Scaled Agile Framework (SAFe)” (no surprise that it’s part of the title of his presentation!)

He built his presentation around seven myths. I wrote them down as:

  • Agile is all you need.
  • <Scrum> is all you need. [Substitute your favorite method for “Scrum”.]
  • XP is too extreme
  • Everything is a user story
  • Architecture emerges
  • Governance and PMO are bad words
  • Leadership and the problem in Chicken and Pig

Among the points he made during his discussion of the first three points: A key to “being agile” is exercising the judgment to assess what practices are right for one environment and using them. No one agile method is assuredly “right” or “wrong” for that environment; each of agile method has great suggestions he recommends each environment consider carefully. Scrum has no software engineering component. That’s neither “good” nor “bad”; it’s the way they built it. A software engineering environment using Scrum may need some software engineering advice (perhaps from XP, for instance). Some environments need all the practices of XP; the right people to decide that issue for each environment are people in that environment.

He referred to non-functional requirements as exceptions to the statement “Everything is a user story”. He referred to non-functional requirements much as IEEE does: “all the -ilities” (maintainability, modifiability, scalability, reliability, security, responsiveness, … there are many more that can be on this list; not all end with “ility”). He indicates agile processes cannot enable software teams to magically ignore these factors; he notes that many agile books don’t mention non-functional requirements. That probably derives from early agile literature aiming at small teams, where very informal approaches to these concerns can be effective. He indicates that as we scale agile, those very informal approaches cannot work. By the same token, it is not possible to write one user story that “completes” any one of these (“security”, for instance). Nor is it likely to be possible to do all work for any one of these within a single iteration. He recommends that teams document non-functional requirements as constraints on the product backlog and review each of those applicable during each product demonstration (that is, each iteration). That periodic review will help keep the non-functional issues alive for everyone and increase chance of success.

For large teams, he doubts it is best to assert that “Architecture Emerges”. Maybe it works for small teams or small numbers of small teams with rich inter-team communication. For him and for larger numbers of teams, the chance of success for the enterprise is too low to depend on the collection of teams to create architecture. They’ll each work largely on local motivations; the enterprise needs a wider view. At scale, he advocates a structure to create an enterprise architecture. It could be a domain architect (or team) writing for all teams. It could be a group with representation from all teams. Other options are possible.

He showed “Eight Principles of Agile Architecture”; they weren’t on the screen long enough for me to capture them. If I remember right, they were the same eight as he discusses just before the halfway point (judging by my vertical scroll bar) in his discussion System Architect Abstract.

He doesn’t feel “Governance and PMO are bad words”. He defined IT governance informally as the things IT executives do to assure IT is fully consistent and supportive of corporate strategies and objectives. He defined PMOs informally as groups of people who understand lots of organizational context and who advise and motivate others to adopt processes most likely to contribute to organizational success. He sees no question that IT needs IT governance as he defined it; he observed PMOs have done lots of the work in some organizations making agile values mainstream.

He doesn’t find the “Chicken and the Pig” analogy useful. As we scale agile practices, we need committed support and contribution from all levels of the chain of command; they all have roles. We don’t help anything by telling anyone they’re “not committed” or “not as committed as I am”. We have no adversaries.

Smaller points he made informally:

  • Don Reinertson’s book The Principles of Product Development Flow (ISBN 978-1935401001) is a great read. It’s difficult to read because it is so profound, but it’s short, too. [Well … he said it’s around 180 pages; some online descriptions indicate it is 300 pages.]
  • Lean has important lessons for us. Your customer is whoever (or whatever) consumes your work; don’t inconvenience them! Lean is a great structure for management to use in working with agile teams.
  • Kaisen: there’s no direct translation. A good translation is, “We can do better.” That’s always true.
  • His least favorite iteration length is 3 weeks. Both 2 weeks and 4 weeks are preferable iteration lengths.
  • Q: Is there a maximum size of a program? A: Dunbar’s number is probably a guide. This is the number of people one person can keep track of in their professional environment. It’s something like 80 to 150. Beyond that, it’s too hard to maintain cohesion in the program.
  • Part of the reason he writes so much is that it helps him understand better.

I hope my taking the time to write this out helps anyone who did not attend get some of the value. Writing it helped me understand better! (grin)

Feedback

In many areas of my past study, feedback is considered good; I consider it important to software engineering life-cycles. I’ll give a definition useful for us here. I’ll mention several examples of feedback in modern life and I’ll apply those thoughts to software engineering life-cycles.

Feedback Defined

Let’s use this definition: feedback in a process flow occurs when a process influences a preceding process.

a process flow with two processes and one arrow; the arrow points from "Build Product" to "Sell Product",
Figure 1. A process flow: “Build Product” is a predecessor to and affects “Sell Product”.

That begs for an example and a picture. At high aggregation, we might say a company that produces product has two processes: Build Product and Sell Product. As shown in Figure 1, the Build Product process is a predecessor of and influences the Sell Product process. (That makes sense: In many cases, producing product makes it easier to sell.) Figure 1 does not include feedback; Sell Product does not influence Build Product.

a diagram similar to Figure 1, but adding a second arrow, this one from "Sell Product" to "Build Product" in addition to the one from "Build Product" to "Sell Product"
Figure 2. A process diagram like Figure 1, except that it adds feedback. Each process is a predecessor to and affects the other process.

Figure 2 adds feedback; Sell Product and Build Product each is a predecessor to the other; each both influences and is influenced by the other.

The feedback might support fiscal constraints; the company might stop production when warehouse inventory gets above a threshold.

The feedback might support customer satisfaction; it might report the results of complaints received, reports of satisfaction, or suggestions for future development.

The concept of a feedback loop is closely related. Figure 1 demonstrates a linear process; it has no loops (or cycles). Figure 2 is an example of a feedback loop.

Corporate Governance

I have heard it said that in parts of the 1900’s, American manufacturing had a relatively easy time designing product that would sell well. A manufacturing organization in that position generates the greatest profit by producing as much product as possible at the lowest possible cost. If variation results in extra cost and doesn’t result in extra profit, they cut variation. Wikipedia describes a 1918 environment in which over half of all U.S. cars were Ford Model T’s. Their black paint dried fastest, which reduced cost on the assembly line. Henry Ford wrote in his autobiography about that time, “Any customer can have a car painted any color that he wants so long as it is black”.

Feedback works. Wikipedia goes on to indicate, “By 1926, flagging sales of the Model T finally convinced Henry to make a new model.” The flagging sales were feedback; by 1927 the company produced the Ford Model A.

Steering Response

A three-year-old recently reminded me in several ways about feedback. She was driving a light and slow electric car; I was jogging beside her interested in assuring her safety. (I’ve later wondered whether I was thinking at all when I put her behind that wheel! There are so many warnings I could have heeded at that time! But I did not …) I didn’t want to be “that” adult in her life, constantly controlling her vehicle; my preferred behavior was to let her do all the steering. (Note to self: you silly man!) I soon realized that she didn’t yet understand the concept of steering this car. She understands steering; she drives her tricycle. On the car, though she held the steering wheel correctly, she didn’t exert enough force on it to change the car’s direction. (In her defense, even truckers might not consider this steering system to be responsive!) Her lack of steering inputs was feedback leading me to take the car to a deserted section of parking lot. We did; she had a great time going either in straight lines or in repeating circles depending how I had most recently set the steering wheel. All was well.

I mentioned this was a three-year-old. After perhaps three minutes of this, she wanted to go to the playground then sometimes within her field of view. Her wish to go to the playground was feedback reminding me about three-year-olds’ tendency toward short attention span.

I set the steering wheel to a position I hoped would get her vehicle to the playground. The vehicle turned well past the direction I wanted. The excessive turn was feedback reminding me that driving a vehicle is an active control process. We cannot set the controls once and be done with it; we must repeatedly check results and adjust the controls again. We get close to one side of the lane, turn away from that side, get close to the lane center, and turn the opposite direction to stay close to the center; we repeat that process all the way to our destination. That process depends on receiving feedback that our vehicle is “close” to an edge or center of the lane. That three-year-old either wasn’t receiving the feedback or wasn’t acting on it.

(By the way, controlling an airplane involves double the inputs. We must start the roll, thus changing the angle of the wings make with the horizon; that’s bank angle. Then we must stop the roll and hold the desired bank angle to turn. Just before we get to our desired direction, we must start rolling toward level. When the wings are level, we must stop the roll. Yup. That’s four control inputs compared to a car’s two.)

Feedback in a Software Development Process

The August 1970 original paper on waterfall software development by Winston Royce mentions the importance of feedback. His Figure 3 shows the classic waterfall diagram also with all feedback flows pointing for each phase “uphill” to the prior phase; the caption is, “Hopefully, the iterative interaction between the various phases is confined to successive steps”. His Figure 4 and the accompanying text recognize the likelihood of detecting problems in testing that invalidate program design and, in turn, invalidate software requirements; the caption is, “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps”. This paper is convincing evidence that we’ve known since the inception of waterfall processes that feedback is useful. And that feedback can be expensive.

The most interesting part of this discussion is deciding how this observation drives today’s software development.

The Agile models answer unanimously: Do a very small part of the project, show it to the customer, get feedback “early and often”, and repeat. Feedback is an important component of the Agile models.

For those of us not using Agile, a useful answer is to divide the project into a series of shorter efforts, each of which completes one development cycle. Perhaps doing more development cycles will make some methodology processes or products excessive; we might find we can streamline those excesses to everyone’s advantage. There is perhaps a reasonable minimum cycle time advised by Agile: one to four weeks; if your organization gets to that point, it has done lots of the change needed to do all of Agile.

This post reviews feedback; feedback is good. We use it in many activities of our lives; in some parts of our lives, we use it without noticing. It is a valuable part of all software development. May we all have and use lots of feedback in our software development!

Iterative Deployment or Big-Bang?

Let’s say your CEO asks for input: “Should an up-coming software development project use an iterative development process?” (Let’s take the question as assuming an alternative of deploying the software product all at once.)

Iterative development means that the software development team team delivers the product functions in a series of small efforts adding up to the whole rather than as a single effort. It can mean (but doesn’t have to) that the end customer sees several deployments.

The Agile answer is clear; the pre-Agile answer may surprise some Agilists. Let’s do pre-Agile first.

Capers Jones released a highly respected book on software cost estimating in 1998; he released a second edition as Estimating Software Costs: Bringing Realism to Estimating (ISBN 978-0-07-148300-1) in 2007. His book (p 479) says that systems and commercial software requirement tend to change at an average rate of “about 2 percent per month from the end of initial requirements until start of testing.” It further says to expect “12 percent for Agile projects”. My experience cannot support contradicting this book.

Maybe that rate of change results from those specifying requirements learning more about the environment in which they’ll use the tool. Maybe that’s a change rate in business. Maybe it measures the amount humans tend to change their minds. Whatever it is, it seems to happen in lots of projects (maybe some of yours!)

Two percent a month doesn’t sound like much, right? Even using processes that ask the user to commit to no further requirements change after establishing a requirements baseline, the development organization ought to be able to be that flexible, right?

How long is your pre-Agile project? Let’s say it is a year, with three months at the start for requirements and two months at the end for testing and deployment. Dr. Jones’ book is telling us that on average, 14 percent of requirements will change in the seven months between the end of requirements and start of testing. And that for an 18-month project, 26 percent of requirements will change. By any chance, do you feel like shortening the project yet? Maybe it makes sense to do a small project with only part of the product function; maybe a six month project or even shorter?

That argument has been around for quite a while. Companies that scheduled projects for long durations didn’t hear it or didn’t find it persuasive.

If the CEO asks me that question, I’d suggest starting with a short project. And since nothing in that logic depended on the current process in use (Agile or otherwise), I’d almost always suggest that. (And it would be easy to say I’d “always” suggest that; it’s just that “always is a very strong word”!) That’s my pre-Agile answer.

The Agile answer: Oh! It’s like they saw this coming!

The Agile answer is to start with a “project” the length of one iteration (commonly, two to four weeks). Agile teams ask their users to make no change to user stories in the iteration once the iteration starts. (Geez! That sounds a lot like the pre-Agile request to let the programmers work on unchanging requirements. And … it makes sense in both places, though it sounds easier to implement in Agile!) Holding user stories unchanged for two to four weeks (and then not all user stories; only those in the iteration) seems lots easier to ask of our customers. At the end of the iteration, Agile teams look forward to showing products to their users and to getting feedback “early and often”.

So … what’s the difference in responding to that CEO question now that Agile is growing into so many of our work processes? Maybe in the pre-Agile days, we wouldn’t have felt comfortable proposing so short a project, though we would have suggested something shorter than “all at once”. Maybe Agile is, in this respect, the direction we were heading anyway!

(By the way, Chapter 7 of Dr. Jones’ book covers “Manual Estimating Methods Derived from Agile Projects and New Environments”. He presents data on many processes, including Scrum and Extreme Programming. It’s good reading.)

Servant Leadership

From my earliest days of learning about leadership, I recall getting advice like these:

  • “The first challenge of leadership is to catch your people doing what you want them to do because reinforcing that performance gives you more of it in the future.”
  • “Among the most important skills of a leader is to tell people what you want them to achieve and then get out of their way so they can surprise you with their ingenuity.” (similar to a statement attributed to George S. Patton)
  • “It’s easier to get results with honey than with ballbats.”

Have you heard those? Similar?

I have always aspired to use those leadership techniques wherever possible. My ability to use them effectively and consistently has grown and, I hope, will continue to grow.

Sometimes, those techniques aren’t appropriate to a situation. (For example, I have never heard of any organization remotely similar to the military using these leadership styles with their newest recruits! Can you imagine that “boot camp” or “police academy”?) Indeed, some students of leadership teach situational leadership to reinforce that leaders must adapt their leadership style to the situation.

In recent years, many of the standard-setters for parts of the Agile community have adopted “servant leadership” as a key transition point for organizations aspiring to agility. Many talk about the Agile Leader (a more general term than Scrum Master) working for the agile team (distinct from the team working for the leader). Should the team ask the Agile Leader a question, much Agile guidance proposes an answer in the form of, “That’s a great question! How do you think our team should answer?” Many times, such guidance instructs that the purpose of taking no position is to give the team the largest possible space in which to innovate. And such guidance instructs that there is no better way to empower the team or to build their ownership of the process and the product.

This guidance has been around for years. And has been valuable for all that time.

Whether you are working on an “Agile” team or a team using “more traditional” processes, I wish for you that all the leaders in your environment (you, included), find their leadership of first resort to be servant leadership. My experience makes me believe you and your teams will be happiest, most invigorated, and most productive when the leader serves. All the best …