Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Hey, it's HighScalability time:
It was a game of drones.
Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...
My most recent post about how to¬†Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.
I use paper. Here’s why I don’t use a tool:
This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)
I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today.¬†As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I¬†will discuss other people’s writing.
Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.
I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.
Could I do this on an electronic board? Of course.
However, I limit my WIP by staying with paper. I can’t add any more to the paper.
Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?
I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban.¬†(See my book review,¬†Book Review: Personal Kanban: Mapping Work | Navigating Life.
You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.
I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.
Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.
How does an organization‚Äôs leadership style affect the adoption of Agile. The focus of the question oft-times begins as a question about teams, which I generally steer to a discussion of the tendency of the organization or at least the senior leadership. The organization‚Äôs leadership culture (usually the same as the senior leaders’) are a leading indicator of whether Agile can take root and grow. There are numerous leadership styles, some are more conducive to adopting and keeping organizations Agile. If we consider ten of the more prevalent leadership styles, there are some that are conducive to Agile and some that are downright hostile. ¬†¬†
The styles with the most filled in Harvey Balls are typically the most conducive to adopting and sustaining Agile.
The worst of the bunch is autocratic leadership. It tends to follow a path that can be best charted as ‘my way or the highway,’ which is an anathema to self-organization and the flexible structure of Agile. ¬†Alternately democratic/participative, servant and transformational leadership tend to be the best of the bunch because they¬†clash less with overall agile values.
A more in-depth evaluation of the first four follows.
Autocratic leadership is a form of leadership in which a leader exerts high levels of power over his or her employees or team members. Team members (loosely used) are given few opportunities to make suggestions or decisions even in scenarios where it would be advantageous to the team or organization for making suggestions. (Listen to Gene Hughson SPaMCAST 430 describe in more detail why this form of leadership is dangerous.) Agile principles are designed to empower the team to make decisions and to foster collaboration. ¬†Agile principles will always be at odds with autocratic leadership. ¬†In this environment Agile generally, will not flourish and will only take hold in areas that are cut off from autocratic managers.
Bureaucratic leaders explicitly follow the book or the process. This style of work makes sense in some specific areas, for example pilots reviewing the preflight checklist or handling of hazardous chemicals. However, in most cases developing, enhancing and maintain software does not fall into this category. ¬†I use the qualifier, ‚Äúmost‚ÄĚ in a cautious manner, there are lifecycle activities that can be improved by some level bureaucratic management. For example, the enforcement of code check-in before implementation, safety and security testing of software and other operational activities (many of these activities can and should be automated to enforce the process). ¬†In most cases, bureaucratic leadership will smother innovation. Implementing concepts such as backlogs with their emergent qualities or continuous re-planning will be difficult under bureaucratic leadership. ¬†Bureaucratic leadership is bad for Agile, but not quite as bad as autocratic leadership.
Charismatic leadership injects huge doses of enthusiasm into his or her team and is very energetic in driving others forward. If the leader is committed to Agile then this form of leadership is decidedly a plus (thus the mostly filled in Harvey Ball). ¬†The downside of this style is that charismatic leadership tends to foster a cult of personality in which the leader and his or her passions are more important than the team. Further, this form of leadership puts programs, such as an Agile transformation, at risk when the leader changes position. ¬†When the leader leaves, the program can no longer draw on the charisma for energy. ¬†I have seen programs of all types falter when the charismatic leader that championed and lead the implementation is promoted or takes a position outside of the organization. ¬†As a change agent, use this type of leadership to your advantage but recognize the risk and develop other leaders to fill the gap when the leader moves on.
Democratic Leadership or Participative Leadership
Democratic/participative leadership invites other members of the team to contribute to the decision-making process. This form of leadership recognizes that team members bring knowledge, expertise and other points-of-view to the decision-making process. Team members are empowered, therefore they are motivated to work toward the team‚Äôs goals. This form of leadership is very conducive to adopting and embracing the Agile principles. ¬†The downside of this type of leadership is that when a crisis occurs the decision-making process can be slower than autocratic forms of leadership.
Almost every organization wants to adopt or perhaps experiment with Agile. ¬†Agile principles and many of the common leadership practices aren‚Äôt compatible. ¬†A number of years ago I observed a leader that pushed his teams to adopt Agile (Scrumban in this case), only to turn up every morning at stand-up meetings to assign tasks to each person on each team. ¬†The problem was not that he and the teams did not understand Agile but rather his management style was at odds the how Agile really works.
Next ¬†– The Next Six Leadership Styles
Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.
You need a way to say no to more work.
I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)
One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.
These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.
On the right, ¬†you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?
Now, given what I know, I would add WIP limits to each column.
If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see¬†Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)
Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.
Software development is rife with copy & paste: all of us resort to copy and paste coding sometimes. We know we probably shouldn’t, but we do
it anyway. It’s like the industry’s dirty little secret: we mainly just copy and paste code from the internet or from somewhere else in the code base then bash it till it works.
But maybe, just maybe, the fact that we all rely on this from time to time should be telling us something?The good
Sometimes copy & paste coding can be a good thing. A while ago I was pairing with someone where we did what I would call “search and replace coding”. I love to code golf. In tools like Eclipse, Intellij or Resharper there is always an optimal way to make each change, letting the tools do as much of the typing as possible. So it was with fascination recently that a colleague showed me an interesting code golf using search & replace.
The change was around extending an existing class with a load of new fields. We had a basic class, with a couple of sample fields, and a test that verified something simple about the class – say that it could be serialized to JSON successfully. We needed to add a boatload of new fields to the class (don’t ask). This involved five separate tasks which, at a macro level, had a lot in common:
My colleague demonstrated that we could write the list of fields once. Then, copy & paste, search & replace – we have a list of parameters for the constructor. By carefully crafting the search term and a suitable replacement term you can do some limited meta-programming. Taking the list of fields and transforming it into the actual lines of code you need in each instance. The list of fields replaced one way gives you a list of parameters to the constructor; with a different replacement you get the field declarations in the test; with another replacement you get assert statements.
I found this a very interesting way to write software. It definitely optimized the number of key presses required to type the code in. The long, boring list of field names only had to be typed in once; after that merely carefully crafting a search & replace regex to do the lifting for us. But it demonstrates an underlying truth: we had five separate changes to make, which accepted a parameter. If we could have actually meta-programmed this, we would have passed in the list of fields to some meta-programming code which would output the desired lines of code.
While it’s very¬†clever that we could use search & replace meta-programming for this, it feels like the tools are lacking somehow.The bad
Everyone copies code from stackoverflow from time to time. Hopefully you do it sensibly, using it as a starting point for your own production code. Working through what you’ve just pasted in to understand it, experimenting with it, modifying it, making it fit for your purpose. Rather than just blindly copy & pasting random code from the internet. I mean, who’d just randomly run code from the internet?
Stackoverflow is great. It’s an amazing resource for programmers. While learning WPF I got the sense that as a technology it couldn’t have taken off without something like stackoverflow. The technology is so opaque, so hard to learn. It took me many, many months of copy & pasting xaml from stackoverflow until I started to really understand how it worked. This is a technology that is not trivial to understand. Without being able to just copy & paste code from the internet, the technology would take a lot longer to learn.
But often, we’re lazy, we try it. It works. Woohoo, next problem. I’ve written before about voodoo programming, but the problem is that it’s easy to¬†think you’ve understood what code is doing. If you didn’t actually have to invent those lines, to reason through to them – maybe you don’t understand. Maybe you only think you know what the code’s doing? Maybe there’s some horrific bug you’re not aware of yet?The ugly
Almost every time I’ve seen TDD done at any scale, when it comes to writing a new test, the first question to ask is: “which existing test is this most like?” Yup, where can I go copy & paste. I’m so lazy, I don’t want to have to invent a whole test setup on my own. I’ll just borrow somebody else’s homework. We’ve all done it. It seems to be an unwritten rule of TDD. By the time you’re on to the third or fourth test in a given file, I guarantee the temptation to just copy & paste to make the fifth test is¬†incredibly strong.
The trouble with this is all sorts of weird test artefacts get copied forwards. You start off with a simple test, with some simple setup. Say an empty bank account. Then to test non-zero balance you need an account with a transaction. Then to test balance summing you need an account with two transactions. Each test so far is building on the last, so you’ve just copy & pasted the previous one as a starting point. The fourth test is inserting a new transaction, so you just copy the third test (with two existing transactions, unnecessary for this test). Test five¬†is that a withdrawal can’t go below zero, so you copy & paste the previous test and set the amount to be a large negative value. Test six is an overdraft test, so you copy & paste the previous test but change the account setup to include an overdraft so the balance can go negative. By the time you copy & paste test seven, your¬†starting point¬†is an account with an overdraft, with two transactions where a third transaction is added. Test seven is about adding a standing order. None of this noise is necessary.
This might seem a ridiculous example, but I see this time and again in real code. Sometimes it’s not even me that’s done it. This noise accumulates as you read down a test file. The tests at the bottom have all sorts of weird artefacts that were only relevant to one test half way up the file. It means fixing tests and changing behaviours becomes a real problem. If I change, say, how overdrafts are defined in my example above – I might have half a dozen tests to change, only one of which even mentions overdrafts. But they’ve inherited that setup because the tests were just copy & pasted around. Not only does this make tests hard to read and understand it makes them hard to maintain.
We all do it. It seems a pretty accepted part of how TDD happens in the wild. And yet, it clearly isn’t right. With discipline, we can keep our tests clean. Yes, when we’re all being conscientious developers we start writing our tests from scratch each time. But most of the time we’re busy or lazy or whatever.Conclusion
What do these three things have in common, besides copy & paste? In each example we’re using copy & paste to save time. To find the most efficient path through the work we’re doing. Nobody is doing it out of malice or stupidity. Laziness? Almost certainly – but the good kind. The kind of laziness that encourages elegant solutions.
But copy & paste isn’t an elegant solution. It’s a crappy solution to a more fundamental problem: our tools are deficient. Really what we’re working around is the fact that our tools don’t let us express what we really want.
What if we could write our tests in a higher level language? “A test with a bank account with two transactions”. Sure, there are internal & external DSLs you can use to do this. But typically the cost in setting up the DSL isn’t worth the hassle for¬†unit tests. It would completely ruin the flow of TDD. Does that just mean we haven’t found a good way of doing it yet? Is there a way we could more fluidly express the intent of the test, filling in the gaps as we go?
Instead of copy & pasting code from the internet, could our tools get smarter? Could we take some of the amazing machine learning stuff that’s going on and apply it to software development? I tried playing with an IntelliJ plugin recently that promises just that. Unfortunately it’s pretty buggy at the minute and doesn’t really work. But the¬†idea is incredibly attractive. I like the idea of being able to express intent instead of mindlessly typing in the nuts & bolts.
Finally, instead of doing search & replace coding, wouldn’t it be great if we could actually meta-program? If we could actually write code that would write code for us? Not just code generators, but something that can generate small sections of code. I had a very limited go at this some time ago with rescripter – but it turns out its very hard to write a decent meta-programming tool, that anyone except the author can understand. But I think the idea still has merit: too often I find cases where I can describe the intent of my change very succinctly, but implementing it will involve far more typing than I’d like.
I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.
I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:
Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)
Your customers don’t buy points. They buy completed features.
Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.
This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).
Here’s one value of this chart: Until tasks add up to features, you don’t count them.
My participant couldn’t articulate the problems before. The chart helped him see and discuss:
The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.
I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.
I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.
If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.
When I began working in the field of data management the disconnect between rigid structure of relational database tables and free form of documents managed by end users and their businesses stood out as a technical and managerial hurdle. On the one hand there were strict definitions of normalized relational database models and unstructured document formats on the other. Often the users in charge of changing document structures held organizational responsibilities far removed from database modeling or programming. On one occasion I was involved in a project where call center operators made on the fly decisions to update a document structure based on phone conversations with customers. Such updates had to be streamed into a relational back-end creating havoc in database structure and build of table columns.
In seeking a permanent solution I researched merits of Entity-Attribute-Value database schema and its applications. This technique proved successful in enabling front end users to modify relational-bound documents through performing updates to structure described in their metadata. However application of EAV raised its own issues, for example accommodation of updated document metadata at times required changes to definitions of the relational tables, attention of developers due to complexity of application layer in client-server interoperability, rapidly growing fact tables and performance of multiple join statements in select queries...
Coaches and change agents use many types of influence to help teams and organizations perform better as they lead. ¬†Influence can be applied through a number of highly nuanced approaches. And like many activities, when you find success with one it is easy to fall into a trap of thinking that that approach will always work. ¬†While sports analogies are often overdone, I will add one more to the pile before swearing them off (for this essay at least). ¬†The Super Bowl, the pinnacle of US Football, was recently played and featured a come from behind victory. The New England Patriots won the game despite having many of their top receivers sidelined due to injury. If the Patriots had only one approach to the game based on that set of receivers they would have been blown out. A good coach will be able to leverage different forms of influence based on the context they find themselves face or be able to recognize when dangerous forms of influence are being used. ¬†Recently I ran across a list of 7 approaches to influencing teams or organizations. Some of these approaches can be useful for coaches and some are harmful. The 7¬†forms of influence, some good and some bad, include:
Influence is key to leadership and change. There are lots of ways to generate influence some are better than others. Use multiple types of influence, but stay away from fear, bullying and don‚Äôt start a cult of personality. Influence used correctly is the grease that gets things done, but when used incorrectly leads to failure.