Oct

14

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

We’re going to talk today about the product backlog. For those unfamiliar, the backlog is the list of functions or features that the product owner or business want in the eventual product. On a Scrum project, these are usually user stories, a sentence in what I call “Cohn Normal Form” is:

I as type of user, want to perform some function so I can receive some benefit.

For instance: “I, as a customer of the bank, want to withdraw money from the ATM, so I can buy a cup of coffee.”

Read more

Aug

31

I’ve recently been working on a project that is making a very determined try to use Test Driven Development (TDD). For those who are unfamiliar with the practice, rather than writing your unit tests after you write your code, you write the tests first.  I’ve known about the practice for years, but this is the first time I’ve worked on a team that’s really doing it, and I’m no less puzzled than I used to be. Well, we should probably talk about first things first. Read more

May

6

It’s no secret how to write a good user story, you just need to keep focused on the outcome you want to see. Cohen’s formula, “I, as a , want to so I can ,” does a good job keeping us focused on that. Still it seems like people want to throw all kinds of things into the backlog as a user story.

I’ve started to notice, however, that there’s another interesting thing out there, which we’ll call User Story Factories. (I was calling them “story generators,” Lowell Lindstrom, a Certified Scrum Trainer, suggested that maybe “factory” was a more appropriate term, which seemed like a sensible suggestion.)

Sometimes someone will suggest a story along the lines of “we need to educate the organization on our new product.” It’s a pretty sensible suggestion, it’s something that the project needs to do, and it has a business value. It presents some interesting challenges when you consider how you get to “done” with that story.

How do you say you’re “done” with educating the organization? You can’t, because there’s always something else you could do.  You can pull specific stories out of this factory, however. You can decide to offer a lunch-and-learn, schedule training, or visit with teams using the current version of your product. All of these have pretty clear criteria as to what “done” means, but the factory itself doesn’t.

I think this is an interesting tool to keep around. When you’re planning iterations/sprints, you can look at these factories and decide if you need to make some progress in the area they describe.  If so, you pull some stories out of the factory, decide on how you’ll be “done,” and put them into the backlog.

Some of the purists might say “that’s not a good story,” but I think it helps keep your customer/product owner engaged with the project if you can speak in their terms. They’re worried about “organizational education,” then cool, keep it around and decide how to get good stories out of that factory.

Mar

10

Something’s been on my mind, and I need to speak up a bit.  I’ve grown increasingly annoyed by agile practitioners who are slavishly devoted to their favorite agile author.   It doesn’t matter if it’s Uncle Bob, Ken Schwaber or Kent Beck, I think there’s something a little unhealthy in some people attitudes.   I’ve seen trained professionals claim that they can’t do something because “Scrum doesn’t say they can.”  I’ve heard them take umbrage with questioning what their favorite author’s written, as though we were questioning the word of God himself.   How dare we question the word of Schwaber?!? Read more

Feb

24

I’ve been aware that one of the teams at my current client has been experimenting with using SecondLife for their collaborative space.  The project is coached by one of the other agile coaches, and I admit I’ve been curious to see what it looked like.  I’ve been aware of SecondLife for a while now, but never seemed to get around to creating an account or doing anything more than saying “Huh.  That’s interesting.”

Today I got a chance to see SecondLife in action.  The coach, who sits by me when we’re not off coaching teams, was logged in and showing some of the other agile coaches what it was like.  It was really interesting. They’ve built themselves a custom story wall widget, they’ve got a secured building on what seems like a private island, and they were, by chance, having a meeting with some of their stakeholders when we were there.

SecondLife seems like a very compelling idea.  More live than an IM link, somehow more tactile than a conference call.  We watched for a while, and then the next time I looked, one of the other avatars was dancing.  On the conference table.  Well, it’s just a virtual conference table.

I’m not big fan of political correctness myself, but I was a product of corporate America in the 1990s, so I got trained in what some people consider “hostile work environment.”  It really doesn’t take much.

At first I was just bemused by the dancing, but a little later in the day I started to think to myself that it certainly wouldn’t be acceptable conduct to dance on a table in a conference room in “first life,” if you will, but it seemed just fine in SecondLife.  I mentioned it to the coach who was using SecondLife, and he told me that they had been obliged to sign a document attesting to their understanding that the code of business conduct extended to SecondLife as well.

“But hey! It’s just virtual, right?”  I suspect that we’re in for some interesting times, my friends.  As we live more and more in the virtual world, I suspect that courts will view them in much the same was as the original: harassment and other misdeeds, even if virtual, will be something the courts will have an interest in.  Will codes of conduct be viewed as applying to the virtual world? I suspect so, but I think things will be interesting to watch while this get sorted out.

Feb

19

So a colleage and I are going to try to put together a series of courses for data professionals that helps them understand how to work in an agile fashion.  If you have suggestions for topics or other related items for such a course, please let me know!

Nov

6

I’m currently mentoring a team at my client’s site that’s using test driven development (TDD) to improve the design of their application. We’re also using Struts 1.x, and they want to use StrutsTestCase as a standard for testing.  Okay, so far so good.

Being a fan of the Spring Framework, it should be no surprise that I want to make dependency injection a big part of refactoring to make their application more modular.  So I set off, Google in hand, to try to figure out how to make Struts, StrutsTestCase and Spring all play nice together.  Turns out that it can be done, but it’s surprisingly difficult, and I couldn’t find anything telling me exactly how to do it. There were hints in a number of places, but it took me a couple of days to put all of those together.  I’m going to share, so hopefully you won’t have to go through what I did. Read more

Sep

15

We got into an interesting conversation at work the other day regarding the role of risk in an agile project. Perhaps I have an extremely broad definition of risk, but I believe that risk is a primary, and perhaps the most important, thing to consider when running such a project. Read more

Jun

19

Why is it so difficult to get people to collaborate? When coaching agile projects, we always advocate that people collaborate rather than try to find ways to avoid talking to one another, such as by writing documents and making people read them.

The development teams are usually all over this. They want to collaborate with people who they need things from, such as the business owner in order to better understand the requirements. They’d rather just ask questions of a live body than read a document. Oh, sure, occasionally at first they don’t really want to talk to “those other people,” developers do tend to be introverts after all.  Usually once they try it they think it’s much better than the old ways.

Why, then, is it so hard to get the developers to collaborate with people who want the things they produce? I’m thinking specifically here about the usual suspects, I suppose, the database organization, the testing organization, and any sort of compliance/oversight organization. These are the same organizations who usually have a dim view of agile to begin with, for reasons I’ve talked about before. Why is it so hard to convince an development team (and I’m intentionally not saying a ‘project team’ because they don’t have all the right people) to invite someone, such as a tester, to one of their meetings, when in turn they want to be part of requirements meetings?

You could be forgiven for thinking that once they’d seen the value of working collaboratively, rather than focusing on documents and hand-offs, they’d naturally want to start doing more of it, extending that approach to people down stream from them in the development process. Strangely, that doesn’t seem to be the truth, I get a great amount of pushback when I suggest this type of thing.

I don’t think this is a case of “you should change, but I don’t need to,” since the developers are  already changing the way that they work. To me, a more compelling explanation is that they don’t want to confront someone who may be hostile to the way that they’re working. This is probably particularly hard when they’re new to agile, and they’re not used to working this way yet. But you’d think that having seen the advantages, and wanting to maximize the amount of work not done, they’d push the envelope more than they seem willing to.

Even more surprising is when it’s suggested, I get pushback on collaborating! “We don’t want to waste their time,” they tell me, or “It’s not their meeting, it’s ours.”

I guess life is just full of people behaving in ways that seem harmful to themselves, and that surprises me.

Apr

9

I’ve been thinking a lot lately about the challenges of really doing SOA for an enterprise, and some of these thoughts were crystallized by the first of a two-part paper at InfoQ called “Beyond SOA“. It’s a bit of a challenging read, at least for me anyway. They’ve got some good points, that you have to identify the business as a system of interrelating units (subsystems) and that you have to design around real-world events and real-world entities. The author also believes that even the business stakeholders have an incomplete view of the problem domain, and they’re probably right:

 “A fundamental difference exists between an enterprise operator and an enterprise designer. To illustrate, consider the two most important people in successful operation of an airplane. One is the airplane designer and the other is the airplane pilot. The designer creates an airplane that ordinary pilots can fly successfully. Is not the usual manager more a pilot than a designer? A manager runs an organization, just as a pilot runs an airplane. Success of a pilot depends on an aircraft designer who created a successful airplane. On the other hand, who designed the corporation that a manager runs? Almost never has anyone intentionally and thoughtfully designed an organization to achieve planned growth and stability. Education, in present management schools, trains operators of corporations. There is almost no attention to designing corporations.”

And I’m with him so far. Designing services for the enterprise requires an uncommonly broad view: not only how the business functions, but how the business as system should function. But from there, the author makes some surprising suggestions:

We propose a fundamental change to how we architect and design information systems, in a way that will not require business stakeholders as the primary input. We recommend utilizing a framework centered on business entity lifecycle and event-model as the primary sources of input into the architecture. Business scenarios are used only as a post-architecture fine tuning exercise, instead of the main driver.

This framework-first approach accounts for the dynamic of the business from the beginning, and is not an afterthought. It implies that the designed enterprise application is dynamically adaptive, instead of statically adaptive as it is implemented by today’s methodologies. This cuts the cost of developing and maintaining software by orders of magnitude and cut into the over 70% of IT spend that is directly linked to changing and maintaining existing systems.

and most incredibly to me

A framework-first approach capable of integrating business changes into IT implementations and providing a clear translation between business and technology could raise the success rate to close to a 100 percent. Architecting complex systems could take days instead of months or years.

I’ve dealt with producing enterprise-grade systems for years. I  believe that treating an enterprise as a set of interrelated subsystems is a worthy idea, one that is particularly challenging because of the dynamic nature of businesses and their changing environments. When was the last time that your mailing subsystem changed without you looking at the code, after all? I think however it’s cavalier to suggest that a change to this style of development, one that’s incompletely described, can result in success rates of 100% while cutting IT spend by 70%. If you can do that, then I believe you have a license to print money. Until you can prove it, I’m a skeptic.

« go back — keep looking »

Blogroll

WP Themes