Skip to content

Companies

Episode #138 – Principles or Practices

Integrum - Agile Weekly Podcast - Thu, 06/05/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What is more important, principles or practices?
Email
Categories: Companies

Episode #137 – Central Control

Integrum - Agile Weekly Podcast - Thu, 05/08/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What happens when someone has central control

Transcript

Derek Neighbors:  Hello, and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Jade Meskill:  I’m Jade Meskill

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich

Derek:  We’ve got another fantastic, hypothetical situation.

[laughter]

Derek:  You may spot this in the wild, I don’t know. We’re talking about things that could potentially maybe happen, someday, to some teams.

Say you had a czar of a department, or a unit, or a job function.

Roy:  Like a real Russian Tsar?

Derek:  Yeah, like an architect…

[laughter]

Jade:  I’m a Marxist, sorry.

Derek:  In the hypothetical situation, we would probably see this as being an architect, or maybe be a designer of some kind. When I say designer, I mean the chief of the companies, the [inaudible 00:55] top guy.

Jade:  Or the head programmer?

Derek:  The head jock honcho.

Jade:  On the team, the technical lead or something?

Derek:  Not even that. Above the technical lead, the top of the food chain. They have this stance that says, “The only thing that can done can only go to production if I have approved it.”

Roy:  You’re saying everything has to go through this guy?

Derek:  Everything has to go through this gal. She is totally 100 percent, “The design, every pixel has to be done by me,” or “Every single method has to be approved by me if we’re writing code.”

This person works in a large organization, thousands of people per se, and lo and behold, they can’t go to every planning meeting.

The good news is they have some mini‑czars that they can send out to these planning meetings. They can go to these planning meetings, and help the developers and the designers do things.

Then what happens is all sorts of decisions happen in a planning meeting. When these mini‑czars come back to the big honcho, the big honcho says, “Nope, I don’t like it. It needs to be this way.” Now they go back to the team and have to tell the team, “Sorry.’”

[crosstalk]

Derek:  …What does that look like? What happens? How do you fix that? How do you rectify that situation? What are the downsides to that stuff?

Roy:  First off, is there anything wrong with that?

Clayton:  Yeah, I’ll take the devil’s advocate approach. The reason that all the design has to go through that one person is because if you want to maintain a consistent brand experience for the end‑user, you can’t just let people ‑‑ especially developers who don’t have any design sense ‑‑ to go off and do a bunch of crazy stuff.

Roy:  There’s a bunch of awesome examples where I’ve seen exactly that with Google. In fact, I’ve heard, Derek, you complained about this specifically that Google has all of these products out there of totally different experiences, that are totally not integrating because they’re all being developed in isolation.

Derek:  Ever since their designs are [inaudible 02:56] left…

[laughter]

Derek:  They have not been on‑brand.

Jade:  I’ve seen these on the development side, too, where you’ve got all these dumb programmers that we hired that are up there writing a bunch of crap. If they could just do it like me, everything would be so much better.

Derek:  Yeah, where do you think our tech‑level of that comes from?

Jade:  Yeah. [laughs]

Clayton:  I suppose we pay these people six figure to be morons.

Derek:  The dumbest, highest paid people, we have.

[laughter]

Roy:  I get that. The guy at the top, his neck is on the line if should go south, he wants to make sure that everything goes north. Right?

Derek:  Yeah, it’s pretty scalable, they are able to ship a lot of production software this way.

Clayton:  That’s a trade‑off. If you go through this bottleneck where one person has to approve everything, obviously everything goes very slowly, and you don’t ship very often.

Jade:  And you redo a lot.

Clayton:  Yeah, you probably use a lot of rework, as obviously the market’s going to change, and you’re going to have to go back and fix things and change your strategy. But theoretically, everything looks pretty good, and it’s pretty close to being “perfect” when it does ship.

Roy:  I guess that depends on their value system then. Do you value the ability to move fast, to make changes and respond to changing requirements in the changing world? Or do you prefer to have a perfect experience? Because I could see value in both of those.

Derek:  Yeah, if a lot of people really applaud Apple and Steve Jobs and what he did ‑‑ he certainly was not interested in shipping on a very tight schedule and going very fast. He was much more concerned about shipping perfect products than he was shipping bad products more frequently.

Roy:  Right. Another example is like Rolls‑Royce or something, where, I don’t care if it has the latest and greatest features, but…Hold on, let’s be clear here. I’m not buying a Rolls‑Royce.

[laughter]

Roy:  I could see people don’t really care about [inaudible 04:46] features, they care about every product being extremely high quality. I don’t know if they actually have this, but I could see them having a philosophy like the CEO hand‑checks every single car before it leaves the factory, because they insist on having that premium experience, and that everything is perfect.

Jade:  Apple’s an interesting case, because they’ve shipped a lot of great hardware. They shipped a lot of really poor software that is not consistent and not very good.

Derek:  You’ve obviously used their online store before.

Jade:  [laughs] Yeah.

Clayton:  I’ve always had a tough time with the Apple comparison. I think that’s the first one that people jump to, but no one ever really acknowledges the difference in hardware.

Jade:  It’s much harder to fix hardware once it’s gone up the book.

Clayton:  Yeah, so that’s different. That’s something that we should clarify.

Derek:  When I look at this hypothetical situation, the thing that I think is the biggest pain for me or the biggest thing that I see that people aren’t talking about, is what does it feel like being a team member who goes through a planning meeting with a group of people and comes up with a solution and an idea only to, an hour later or a day later or two days later, say, “Uhh, what you’re doing is really stupid and really dumb. This is the right way to do it. Throw away everything you’ve done and go do this other thing instead.”

What does that feel like as a team member, do you think?

Roy:  I can see two parts to that. First off, we talked a lot about autonomous teams. I would feel like, as a team member, a large part of your autonomy gets taken away if someone comes back and says, “You have to do it my way.”

If it’s taken from the standpoint of, “Hey, have you considered using other options”? And they are truly better ideas. If you follow the core commitments and you choose to always seek to better an idea and to accept any idea no matter where it comes from, then that sounds like it would only be a positive experience.

I think that how that interaction takes place, and the attitude of both parties, has a huge impact on how that’s going to go down.

Clayton:  I would feel pretty useless and like my time was being wasted. I would probably not even bother attending. Or if I did attend, it would just be for show. I would probably not even be paying attention because, really, what difference does it make?

Roy:  But there is a difference. Clayton, if I came to you. Let’s say you plan on a Monday and I come to you on a Wednesday. I say, “Hey, I saw what you guys planned out on Monday. Have you considered using other possibilities”? Would you have that same reaction?

Clayton:  If you said, “Had you considered these other possibilities”? We had some dialog, and I said, “OK, let’s talk about it next Monday.” I think that would be one thing. If you said, “Put the brakes on. Really think hard about these other choices, because you’re doing them no matter what.” Then I would feel like, “What’s the point. Why did I waste that time”?

Jade:  I can tell you what it’s like to be on the other side of that. I’ve been that person. It sucks. You can’t trust anybody. You are paranoid and you need to be…

Roy:  Just to be clear, what side are you talking about?

Jade:  The person who’s the bottleneck. Who…

Roy:  Oh, I see.

Jade:  …is changing things for everybody.

Roy:  And insisting that your rules be followed?

Jade:  Yeah. It’s a very crappy position to be in. You don’t sleep well. You’re not relaxed. You’re always stressed out because everything is going wrong around you all the time. You don’t trust anybody. I think that’s really where…that’s the core of the issue. You don’t trust anybody.

Derek:  In this particular hypothetical, there’s also a middle person. We’ve not talked about that middle person. Not only is the person that is doing the work probably leaving frustrated…

Roy:  So you’re talking about the Vice Czar in this, right?

Derek:  The Vice Czar goes into this thing thinking, “Oh, I totally represent the attitudes and the patterns and the thinking of my boss.” We go in and I walk out thinking, “Man, this is all going to be really good.” Then I go back and they say, “Why did you make this decision? You’re letting them do that? I can’t believe that”!

Now, not only do I have to feel like maybe my boss doesn’t trust me, but now I have to go deliver that news to a whole group of people to say, “Hey guys, even though I said that this was probably the right thing to do, as it turns out, the Grand Czar does not agree with me.”

What does that got to feel like?

Clayton:  You lose face with the other people. I know that I told you that it was good, or that we agreed that it was good, but it turns out that it’s not. So either I can play that off as, “The czar guy is a real jerk. Man, what an asshole! I hate that guy too.” Or you would have to just hope that people aren’t thinking, “This person is really stupid. They don’t understand what their boss wants. Man, I’m not going to bother asking their opinion anymore.”

Roy:  Right. Even the boss is probably getting frustrated with them. They’re coming back with ideas representing the team. It’s probably not what the boss wants in the first place. They’re never going to think the same way. So this person is probably just getting shit on from both sides.

Derek:  So we’ve got the hypothetical. We’ve got some of maybe how it feels to be all of the roles in the hypothetical. How would you go about fixing it?

Roy:  In my opinion, if you can figure out some way to have the team earn the Czar’s trust and rid the organization of the Czar, not rid of the person but rid of the role, I think that will go a long way. Somebody who is insistent on all of these best practices, good coding styles, good design, or whatever, they should be going out and championing all of those things and explaining why it’s so important and really convincing people and winning them over rather than telling them what to do.

Jade:  A lot of times they do have a lot of really great knowledge and sometimes even some special insight that other people don’t have, but you’re right.

They should be going out and helping those other people to gain that skill and also experience things from the other side of the fence.

The things that are changing during planning or the real complexities on the ground of dealing with this on the fly, those type of things so that there is some empathy for what the people are going through while they’re out dealing with these situations.

But again, it comes back to building trust with those people. You believe that they’re doing the best thing that they can.

Roy:  It gets tough though when you set up a system like that in which you’re like, “I’m the one who is going to decide on the design, so Clayton don’t even bother wasting time coming up with designs or whatever.”

“Don’t even bother coming up with the method definitions because I’m going to shoot it down and give my own implementation anyway.”

Now all of a sudden Clayton hates me, and it’s going to be really difficult for Clayton to earn my trust because he is going to be trying to get away as much as he can to please the people that are breathing down his neck without getting my ire.

He is going to be subverting me, which is going to cause me to trust him even less like that’s just going to be a feedback loop.

Clayton:  There are definitely cases where people get in this situation like what Jade described like no trust and I don’t think most people would want to be in that, but there are some people who do enjoy the aspect of controlling everything.

They want to be the hero and they want to be seen as the smartest guy in the room and all that stuff.

I would say that probably is a pretty big component in a lot of these cases compared to the person who really doesn’t want it to be that way all the time, but it’s just like, “Oh, woe is me,” it just happened to be that way.

There is some aspect to that. I think unwinding some of that desire for control where they don’t feel like all of their self‑worth at their job is based on whether or not they got all the answers right all the time. I think that could go a long way.

Derek:  When I look at it, Steve Jobs might be a good example. I didn’t know Steve and I certainly didn’t see him work, but I would…

Roy:  Me and old buddy Steve, yeah.

Derek:  I think that if I were to…

Roy:  I call him Steve.

Derek:  …guess how he operated, he trusted his people. Because I don’t think he could get the results he got without trusting them. What he wanted to control was the essence of the spirit of the products that were put out.

Not necessarily how they were built and so to me the difference is you come back from a planning meeting and I say, “Oh my God, you’re doing all the stuff wrong and this is how you should have done it.” I don’t think that’s how Steve operated.

He probably operated in a “I’m going to let you do whatever and when you show it to me, if it’s crap, I’m going to say it’s crap, but I’m not going to ship that and fuck you go do it right, and when you get it right, we will ship it. Until then, leave me alone, don’t waste my time.”

“Why did you call me to this fucking demo that sucks this bad”? What I think is very, very different than saying, “I’m going to tell you exactly how to do every little thing.”

I might tell you at the demo to say like “I’m not doing that and I had expected this.” And I think that’s a subtle difference, but that’s very different than trying to control how everybody does their job.

Instead of saying here’s the bar of expectation and I’m going to make you live up to that, I’m not going to tell you how to live up to it.

Jade:  I think that’s right.

Derek:  How do you get somebody to get to the point where they’re allowed to let the essence of what their standard is hold but not have total mistrust.

Jade:  I think there are some systemic problems in that as well that that person is probably being held accountable for those decisions by their people.

Getting some understanding put in place there is a big help. To help their boss see that like they don’t need to be held to that.

They need to be held to the standard of they’re making everyone around them better and helping them achieve that essence and not being a control freak.

Because usually it’s people that don’t want to do that. They end up in that situation because of some externality.

Derek:  Right, fear usually, they’re afraid of something.

Roy:  I wonder if people that are successful at it and managed to climb their way to the top might not be the ones that enjoy it though.

Jade:  There are people that enjoy having that control like Clayton said, and those people might not be able to help them.

Derek:  All right. See you next month.

[music]

Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866‑244‑8656.

Email
Categories: Companies

Episode #136 – Simple

Integrum - Agile Weekly Podcast - Thu, 05/01/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • Simplicity

Transcript

[laughter]

Clayton Lengel‑Zigich:  It is hard doing that every week.

[laughter]

Derek Neighbors:  You don’t do it quite as good as Jade does.

Jade Meskill:  All right, go Roy.

Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water.

Jade:  I’m Jade Meskill.

Clayton:  I’m Clayton Lengel‑Zigich.

Derek:  I’m Derek Neighbors and joining us today is the improv group.

Roy:  In the room next door.

[laughter]

Jade:  Yelling very loudly.

Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been…

Jade:  Accused of being simple?

Roy:  Accused of being simple.

[laughter]

Roy:  Can you tell me a little about what that idea means?

Jade:  Sure. We’ve been trying to…

[shouting in background]

Jade:  These guys are really… [laughs] yelling in there.

[laughter]

Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio.

Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] .

[laughter]

Jade:  Buy! Buy! Sell! Sell! [laughs]

Derek:  You do the savings, I’ll do it.

[laughter]

Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems.

Roy:  What does an over‑complication look like?

Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it.

Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place.

Roy:  It sounds like everything is in the same place, it sounds pretty simple to me.

[laughter]

Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together.

If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces.

Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together.

Roy:  So why wasn’t it obvious to be that way in the first place?

Jade:  Because in the beginning that would have actually been more complex.

Roy:  So how do you know when you are doing something complexly instead of simply?

Jade:  I think when it becomes hard to explain, it’s probably too complicated.

Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that…

Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control.

Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that?

Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well.

Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering.

I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple…

The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do.

Jade:  Yeah, I think being simple is hard.

Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?”

[laughter]

Jade:  We have an observer. Let’s find out…

[crosstalk]

Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build.

Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.”

At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time.

Roy:  What drives that, though? Why do we want to overcomplicate things?

Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.”

“Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…”

“Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality.

Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re…

Jade:  You mean incremental development?

Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it.

To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things.

When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk.

Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value.

I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent.

Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be.

Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.”

You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.”

Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.”

Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.”

Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on.

Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we can’t do that because you didn’t tell us.”

In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for.

Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed.

Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support.

Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database.

Having a database was a non‑trivial thing, so we used the file‑system. We had a table with a row and a column in it. That’s all there was.

Derek:  A folder with files in it?

Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f‑ing crazy? You can’t use the file‑system…”

[laughter]

Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long‑term solution, but it’s going to be as long‑term as it needs to be for what we want to do with it.

Jade:  It was very simple to replace.

Roy:  Exactly.

Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development.

So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!”

And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.”

Jade:  Anything can use this API

Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better.

Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do.

Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro‑applications that had very discreet functionality.

We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co‑mingling of functionality between different classes and you know, the abstractions were good enough.

We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed?

Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board.

In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together.

Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely.

Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things.

Jade:  Everything

Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things.

I think there are this kind of. It is nice to assemble them small‑ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome.

Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed.

Roy:  Yeah

Clayton:  So you start rewriting them yourself

Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps.

I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re‑used inside of those editors.

Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated.

Derek:  Right.

Jade:  Now you find a simpler way to merge those things together.

Derek:  It goes back to; it’s always easier to get more complex.

If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with.

Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces.

Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things.

You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know.

From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app…

[laughter]

Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.”

Derek:  Let’s get good at working together.

Jade:  Yeah, let’s try those things first and then you know, you can juror me to death.

Roy:  Hey I will see you next month

[music]

Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest.

Presenter 2:  Looking for an easy way to stay up to date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile‑content delivered weekly for free.

The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona.

For old episodes check out inagramtech.com or subscribe on iTunes.

Presenter 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free, call 866‑2448656.

Email
Categories: Companies

How to handle Tickets during Sprint Planning?

What is your real objective? To plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?

Categories: Companies

Open Source at Zutubi

A little madness - Fri, 12/07/2012 - 09:07

At Zutubi we’ve reaped massive benefits over the years from open source. We’ve contributed back bits and pieces in that time — feedback and patches — but always felt we could do more. You may have noticed recent posts here about some of our projects, but we thought they deserved a bit more attention. So we’ve recently launch an new open source section on our website. This is a home for a few small projects of our own that we’ve opened up to the community. We hope you find them useful!

So far we’ve listed three projects:

  1. android junit report: a custom test runner for Android projects that produces XML test reports in a format similar to the Ant JUnit task.
  2. zutubi android ant: a collection of Ant tasks that supplement the standard Android build tooling.
  3. zutubi diff: a Java library for reading, inspecting and applying patch files in unified diff and other formats.

Over time we hope to publish more of our work in this way. You can keep an eye out for new projects on our website and/or follow our organisation on GitHub (or indeed my own GitHub account for Android-specific projects).

And as always: feedback is welcome, so fork away!

Categories: Companies

Android JUnit Report Updates

A little madness - Wed, 10/24/2012 - 02:47

Recently I’ve made a few updates to my custom Android test runner, android-junit-report. This runner makes it easy to integrate your Android test results into a continuous integration process by producing de-facto standard JUnit-style XML reports. The latest changes bring the runner up to speed with the latest version of Android and include better documentation. A summary of the updates follows:

  • A new home page for the project.
  • Within the home page, full documentation.
  • Updates to where the reports are written by default. The runner no longer attempts to use the internal storage of the test application, instead it always defaults to the internal storage of the main application (i.e. the one under test).
  • Support for a new __external__ token that allows you to place the reports in the external storage area of the application under test (given availability and permission to do so).
  • Changes to the token syntax to avoid the need to escape when calling the runner via a shell.

I’d like to acknowledge the help of Sebastian Schuberth and Christopher Orr in fine-tuning some aspects of the runner for this release. The latest runner version, 1.5.8, is available for download now.

Categories: Companies

PMI Atlanta Chapter Agile Local Interest Group

Dennis Stevens and Associates - Thu, 03/17/2011 - 03:54

Last night was the inaugural meeting of the PMI Atlanta Chapter Agile Local Interest Group. This group will meet on the third Tuesday of every month to provide Agile speakers and events to support the Agile Project Management community. I am heading up the LIG with a great group of volunteers including Phyllis St John – who has been instrumental in getting the LIG up and running. Cox Enterprises provided that space and John Kosar from CCCI sponsored dinner and coordinated the space.

I was the presenter last night. I did an introduction to the roots of Agile and talked about Knowledge Domains around the new PMI Agile Certification.

Agile Fundamentals

View more presentations from Dennis Stevens.

Thanks to everyone who attended and provided input on what you would like to see from the LIG.

Mike Cottmeyer will be presenting next month. I will post details here on the location as we get that sorted out.

Categories: Companies

PMI Agile Certification

Dennis Stevens and Associates - Fri, 02/25/2011 - 19:19

PMI regularly surveys project practitioners to identify trends in the practice and needs related to project management. One of the practices that PMI has monitored over the last several years is the continuing growth and usage of Agile practices in project management. Since Agile is a topic of growing importance in project management many project professionals are eager to gain Agile techniques to apply on the job. Similarly, organizations that utilize project management to serve both internal and external clients are seeing value in Agile methods to deliver projects for these clients more quickly.

Because of these changes in the project management environment, PMI is developing an Agile certification. This certification will complement the existing PMI offerings in Agile, such as our Agile Community of Practice, SeminarsWorld and eSeminarsWorld classes, and Global Congress area of focus sessions.

My entire focus over the last decade has been responsibly connecting Agile and Project Management to help organizations deliver technology that makes a different to the business. I am passionate about where PMI is going with this. Over the past year or so, I have invested significant time and travel in the groups that are helping connect Agile and the PMI community.  These efforts include:

Agile Certification Overview

I have talked about why I value certification and what certification means previously. I am an advocate of communities generating shared language and exploring how to do what they do better. And I believe that a certificate that exposes a basic understanding with that community is valuable. There is a HUGE gap in understanding between the traditional Project Management practitioner and project management based on an Agile foundation.

PMI’s Agile Certification builds on six key competency areas. Here are the six key areas and a conceptual view of how they may contrast with traditional thinking. Pragmatically, these all exist on a continuum. The key is that most organizations lean toward the traditional side of the equation and that most Project Management implementation put up barriers to delivering projects with practices that lean toward the Agile end of the continuum.

1. Value Driven Delivery

Agile: Deliver value by understanding and prioritizing what is important to the customer and the business, continually refining the smallest and simplest thing that might possible work, delivering quality results incrementally, and obtaining feedback to improve the result.

Traditional: Define the project up front. Use robust change management to protect against / prevent change.

2. Stakeholder Engagement

Agile: Establish and maintain mechanisms that ensure that all current and future interested parties are appropriately participating throughout the lifecycle of the project.

Traditional: Throw projects over the wall across Analysis, Design, Development, QA, and Production. Engage end-users at the end. Leave significant strategic decisions to the interpretation of the development organization while the project is in the black-box of development.

3. Boost Team Performance

Agile: Boost team performance through creating an environment of trust, learning, collaborative decision making, commitment and conflict resolution, thereby enhancing relationships amongst individual team members.

Traditional: Focus on resource optimization. Form teams around projects. Share resources across multiple projects simultaneously. Take power away so people just do what they are told according to the standards. Put all decision making into the hands of few key managers.

4. Adaptive Planning

Agile: Work with the team and the stakeholders to produce and maintain an evolving plan from initiation to close based on goals, business values, risks, constraints, and stakeholder feedback.

Traditional: Plan the work and work the plan. Stick to the Gantt Chart.

5. Problem Detection and Resolution

Agile: The team identifies problems, impediments, and risks; determines strategies for dealing with them; and executes the strategy.

Traditional: Management identifies problems, impediments, and risks; determines strategies for dealing with them; and executes the strategy.

6. Continuous Improvement

Agile: Improve the quality, effectiveness, and flexibility of the product, process and team and influence the organization in order to better deliver value now and in the future.

Traditional: Perform lessons learned at the end of the project. Use those to update organizational processes and standards.

Summary

If you are a traditional and experienced project manager you may not agree with the dichotomy between Agile and Traditional that I presented above. This is either because you view the Agile approach as irresponsible or because you believe you apply Agile in situation specific ways without having to call it Agile. In theory, I agree. In practice I see way more traditional project management than agile project management. Right now, most organizations don’t even have language or feel it is safe to discuss how Agile fits in.

Having open and responsible discussion around the concepts of value drive delivery, stakeholder engagement, boosting team performance, adaptive planning, and continuous improvement can do nothing but help organizations improve performance.  I don’t believe PMI has gotten it perfect in this effort. They have made great progress toward establishing language around the important conversations and have expressed a desire to evolve this body of knowledge rapidly. Creating the Agile Certificate will create safety for organizations to explore the Agile options responsibly.  I am excited about the where the Agile Certification today and where it is heading in the future. But, within five years – I hope that these Agile concepts aren’t controversial. I hope they just become part of the generally accepted way of delivering projects.

Follow the conversation on Twitter at #PMIAgileCert

Categories: Companies

Reflections on #10yrsagile – What is Value?

Dennis Stevens and Associates - Mon, 02/21/2011 - 02:12

On February 11-13, 2001, a group of 17 people came together and created the Agile Manifesto. This launched a decade of dramatic change in the way software projects are delivered in many organizations. A decade later, on February 11-12, in the same resort in Utah, 33 people got together to discuss the Agile Manifesto and talk about what is next. There was a lot of  great discussion and a lot of agreement. What was interesting to me was that there was a lack of agreement on what the last bullet,

“Maximize Value Creation Across the Entire Process”

even means.

Working Code as Value

The first principle behind the Agile Manifesto is:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

To many in the software development community – including many of the attendees at the 10 Years Agile workshop, value means working, tested, deployed code. I agree that this is important, but this is not value. Working, tested, deployed code is captured in the first bullet:

“Demand Technical Excellence”

But does this deliver any value? Quality software is necessary but not sufficient for value delivery. Some in this community view quality software and software craftsmanship as the final purpose. There are some that feel that this was all that in the control of the members of the Agile community. I don’t share this perspective. Value not only has a broader meaning than this, but this limited perspective can actually be value destroying.

Organizational and Personal Values

When we were defining Value-based Development – it was marked up to be Values-based development by someone. Within the agile community, there is a metaphor of software development teams as pigs surrounded by chickens and seagulls. The pigs are committed to development the chickens are involved and the seagulls just fly in a crap all over everything.  The pigs are management and the seagulls are management.  This metaphor comes from the difficult organizational environments that many developers have worked in.  There are some in the community that consider value to be improving the conditions that people work in every day. This is captured in the second bullet:

“Promote Individual Change and Lead Organizational Change”

This is valuable, but does this deliver any value? Improving the environment that individuals work in is really important. Software development is a creative endeavor, it is critical to create an environment where people feel safe and motivated so they can do great creative work. Some in the community view this as the real motivation behind the Agile community. They feel that Agile software development is about what’s in the best interest of the developers. Organizational and Personal values are key – but they aren’t value. In fact, a singular focus on improving personal values can be value destroying.

Value as Customer Value

There is a strong movement emerging in the Agile community, or the post-agile community, that agile is about customer experience. Customer experience is critical to get people to use your product. Customer value is the difference between what a customer gets from a product, and what he or she has to give in order to get it. Customer value is really, really important. Google is my favorite search engine. They absolutely understand what customer value is. But they don’t stay in business on customer value. They make money from advertising and a lot of other things other than search. Again, customer value is necessary but not sufficient. Too narrow of a focus on customer value can lead to a failure of the business. I agree that customer experience is underserved in the Agile community. I believe that Customer Value is a key component of the fourth statement “Maximize Value Creation Across the Entire Process.” But, it is not the entire story.

Value as Economic Value

Eli Goldratt, in “The Goal” defines the making money today and into the future. This is about economic value. There are multiple views of economic value.

Business Value: Increase or Project Revenue, Reduce or Prevent Costs, Improve Service, and Maintain Compliance in alignment with the organizations strategy.

Cost of Delay: the cost to bear as a result of delay in investment.

Risk: An obstacle to Business Value.

Businesses are economic enterprises. Any view of Value that doesn’t acknowledge this is short-sighted. Agile is about quality software, organizational and personal value, and customer value. But at the end of the day, Agile is about improving the ability of the organization to improve economic outcomes.

Summary

Just like Agile, value is not well defined. And different people have different perspectives of value. Even when faced with the options, they decide that some of them are not important. I am a strong advocate of all the aspects of value – and Agile organization’s must setup guard rails to ensure that technical, personal, economic, and customer value are held in high regard. But they are a means to an end – not  an end unto themselves. There are parts of the Agile community that not only view these as an end unto themselves, but that promote the idea that a focus on economic value is actually bad. I don’t share this perspective. Agile is about improving economic outcomes. Technical, personal, economic, and customer value are enablers of this end. Doing these right helps deliver economic outcomes. Focusing on these outside the context of economic value is destructive.

Categories: Companies

Deciding “What” To Build

Dennis Stevens and Associates - Sun, 02/20/2011 - 18:18

This is my presentation from Product Camp Atlanta. I address two big issues facing product management. First, establishing an approach to connect product strategy with business strategy, customer value, and risk. It provides the structure for feedback and rapid reassessment of the product road map (backlog). Second, the presentation demonstrates how to leverage the model to reduce the miscommunication, over analysis, over design, and over engineering that leads to scope creep and misalignment between the desired solution and what is actually delivered.

Deciding what to build View more presentations from Dennis Stevens.

Categories: Companies

What’s Next for the Agile Manifesto

Dennis Stevens and Associates - Sun, 02/13/2011 - 16:35

This weekend, about 33 people got together at the Snowbird Cliff Lodge to celebrate the 10th anniversary of the Agile manifesto. This group was invited and hosted by Alistair Cockburn. The goals were to have a celebration, talk about the successes achieved and the problems facing the community, and hopefully contribute something back around the problems that we can sensibly address.

This is not a replacement or an extension for the Agile Manifesto. It is more of a focusing statement relevant to our understanding of today’s problems and needs. There was a lack of alignment at some levels – although the expected disconnects, Kanban vs Scrum vs XP or whatever, didn’t arise. The biggest lack of alignment I saw was between those that feel we need to address Agile across the business and the group that believes Agile is about only software development, asking “Who are we to be describing how the organization should be designed?” I believe this gap has at it roots the different perspective of the people who attended. Some work within software development teams. Some help organizations adopt Agile. And some help organizations exploit the Agile ability to rapidly deliver working increments of value to update business models and deliver on new value propositions.

But there was a ton of alignment on some issues. There was great energy and flow in the room. There was some negativity and cynicism that came from our focus on what problems exist. But that was the exercise – identify problems that we can sensibly address. I found the entire weekend to be valuable and enjoyable. And I believe we came up with something of value as well.

Process

The facilitators had identified seven categories of questions or issues that had been identified through pre-session interviews with some of the attendees.

  • The Future
  • Training
  • Technical
  • Culture
  • Enterprise / Other Communities
  • Value
  • Agile Backlash

After an initial group warm up, we broke into seven groups with each being assigned to an area. We worked to identify the gaps or issues that need to be addressed in the industry today in our assigned area. We then we rotated around the room in our teams to review the other areas, adding any additional issues we identified and moving some issues from one category to another. We then went back to our original categories and identified underlying themes from the issues. These became the big problems that needed to be addressed. This was great conversation within our groups and the underlying themes were pretty clear and consistent. We then did a read out of our themes to the bigger group and had some additional discussion.

Then we took a five hour break.  Some people stayed and did more work, some napped, some when skiing. I went up on top of the mountain with Alan Shalloway, Joshua Kerievsky and Ahmed Sidky. The view was awesome and I really enjoyed the company and the conversation.

When we reconvened and worked to consolidate the big problems under the following headings.

  1. What problems in software or product development have we solved?
  2. What problems are fundamentally unsolvable?
  3. What problems can we sensibly address — problems that we can mitigate either with money, effort or innovation?
  4. What are the problems we don’t want to try and solve?

We then grouped the problems under “What problems can se sensibly address” into themes and dot voted to identify the biggest issues. Finally, we worked to craft a sentence to address the four top themes. This became a challenging process as there were 30 strong willed people with different perspectives all trying to influence the sentences. As we narrowed this down through our consensus process there was a lot of discussion and debate. At the end of the allotted time we had the following.

We, the undersigned, believe the Agile community must::

  1. Demand Technical Excellence
  2. Promote Individual Change and Lead Organizational Change
  3. Organize Knowledge and Promote Education
  4. Maximize Value Creation Across the Entire Process

Demand Technical Excellence

At the end of the day, you can’t deliver value through technology if you are not delivering quality. This category brings in aspects of architectural, engineering, and design. This is still a pressing issue and must be addressed in the community to deliver on the promise of the Agile Manifesto.

Promote Individual Change and Lead Organizational Change

Here is an example of a sentence that we had a broad range of perspectives on. Without adoption by individuals and alignment of organizational governance and management models, Agile won’t deliver on its value proposition.

Organize Knowledge and Promote Education

This isn’t just about the practitioners, it includes the broader business context as well. The community needs to build on the broad body of knowledge that exists within and outside the community – we have to avoid reinventing everything. Diversity of thought is important to the ongoing growth of the community – but we don’t actually do a very good job of intentionally building on the body of knowledge.

Maximize Value Creation Across the Entire Process

Software Development is not an end unto itself. Too many organizations moving toward Agile are focused on just the software development team. This is only valuable to the point that the software development team is the constraint in the organization. We need to learn how to do a better job of defining value and aligning the cadence across the organization and improving the flow of value from concept to delivery.

Closing Thoughts

This was a dynamic crowd with a lot of experience. In this group, there was very little contention between flavors of Agile. Everyone was open and working to address the needs of the industry and the broader needs of the communities we live in. There are lots of problems – I am sure there will be a lot of talk about “The Elephants” – problems that didn’t explicitly make the list. There will be some dissenters. And I think there may be some work to refine the sentences. Hopefully without losing the meaning of the points.

I believe that Alistair’s goals were achieved. We had a nice celebration – we came to consensus (although not unanimous agreement) on the big issues in front of us. And we shared a lot of energy and community. I got to meet and develop relationships with a number of amazing people. And we ate and drank a lot both nights. I don’t know what comes out of this effort in the bigger community. Now, let’s see how the Agile community responds to the outcome.  I hope we rally around the big issues and continue to improve where we work and the value we deliver.

Categories: Companies

10 Years Agile–Friday Night

Dennis Stevens and Associates - Sat, 02/12/2011 - 16:03

Attendees

Here are the people that are in Snowbird for the 10 years Agile celebration.

  • Pekka Abrahamson
  • Scott Ambler
  • David  Anderson
  • Mike  Beedle
  • Tracy Bialik
  • Alistair  Cockburn
  • Rachel Davies
  • Michael Feathers
  • James Grenning
  • Robert Holler
  • Jonathan  House
  • Erik Huddleston
  • Michael Hugos
  • Zhon Johansen
  • Kay  Johansen
  • Ralph Johnson
  • Nate Jones
  • Joshua Kerievsky
  • Jon Kern
  • Phillipe Kruchten
  • Janice Linden-Reed
  • Todd Little
  • Ryan Martens
  • Eric  Olafson
  • Jeff Patton
  • Russ Rufer
  • Alan  Shalloway
  • Ahmed  Sidky
  • Andrew Shafer
  • Dennis  Stevens
  • Jeff  Sutherland
  • Arline  Sutherland
  • Ghennipher  Weeks

Friday Morning

I spent the morning with Ahmed Sidkey and Alistair Cockburn working on some ICAgile activities. We are trying to get the Business Analysis and Project Management tracks up now that Agile Fundamentals has launched. I am working with the Business Analysis community to coordinate the BA track and bringing the PM work from the recent (and ongoing) efforts of Alistair, Ahmed, Mike Cottmeyer, Mike Griffiths, Michelle Sliger, Jesse Fewell and others with PMI to define Agile PM.

Pre-Cocktail Party

After riding up to the conference, I got to meet and spend time with Tracy Bialik, Alistair, Ahmed, David Anderson, Alan Shalloway, Janice Linden-Reed, Phillipe Kruchten, Erik Huddleston and others greeting, catching up and talking about our expectations for the weekend.

Cocktail Party

At 8, we had a cocktail party where we met Janet Danforth and Robert Moir. Janet and Robert will be facilitating the Saturday morning discussions. There were questions spread around on tables that had been solicited from attendees by the facilitators prior to the event. They were divided into several categories for us to review and discuss. I spent some time at a table with a number of people including Ahmed Sidkey, Jon Kern, Erik Huddleston, and Scott Ambler. The discussion started off around how to get other communities (BA, PM, QA, etc) involved in the Agile. We ended up talking about resting heart rates and food densities – so while it was interesting at the moment I’m not going to blog about it here.

I then spent about half an hour in a discussion with Erik about his approach to scaling agile at his organization. He has courageously built on Dean Leffingwell’s model. He is implementing small fungible teams (high performing teams with the ability to deliver a working increment of software across the portfolio) and is using Kanban at the Program level to feed and coordinate the teams and to dynamically match capacity to demand. Then he is using Kanban downstream from the teams to coordinate integration testing, implementation, and production. This is a pattern that I have seen work well and have seen emerge from multiple directions. Mike Cottmeyer and I have been using this model as a kind of reference architecture for businesses and have had success. I believe this is an organizational adoption pattern that we will see more of.

Later I was involved in conversation with Jeff Patton and Rachel Davies talking about various topics. One was how hard it is to define explicitly how to apply certain practices when coaching teams since we tend to morph them to the moment and are always applying new concepts and ideas. Jeff is gently introducing A3 type thinking into his clients – something that we are starting to do more of – so it’s a validation of a pattern that makes sense. Jeff and I talked about how capability analysis and story mapping share some underlying patterns that seem to make sense. Rachel talked about how hard it is to to get organizations to change and how organizations seem to get stuck in destructive behavior. Jeff brought up this video as something he shows in his class to help people to recognize how they participate in their organizational dysfunction. It is pretty funny.

After Party

We had an after party from 9:00 – 11:00 where we drank Cockburn port and had more conversations. I spent some time talking to Alistair and then got to spend a while with Joshua Kerievsky and Mike Beedle talking about how important the underlying enabling technologies were to doing anything agile.  We also talked about how Scrum and XP have morphed and how implementations must be situation specific.

Summary

There are a lot of people here from various communities. Lean, Scrum, XP, etc. It would be fun to do social network map of who is connected to who in this group and what those communities look like. There was a lot of engagement and energy last night and I didn’t see any conflict. The themes of post-agile, situation specific morphing of practices, and scaling patterns were pretty common place. Today, we have a four hour facilitated session that should be interesting.

Categories: Companies

Agile Business Analysis – Deciding What to Build

Dennis Stevens and Associates - Fri, 01/28/2011 - 16:18

Wednesday night I did a 15 minute talk to Scrum Atlanta on Wednesday night. This was part of a series of talks on “How to do Agile Analysis”. I talked about deciding what to build. Mike Cottmeyer talked about how to break down & chunk the work. Bob Vincent talked about Progressive Elaboration & Specification. This was followed by a 45 minute fish bowl discussion. This topic is becoming increasingly important to organizations as Agile becomes more common in organizations and the session received good feedback from attendees.

An introduction to agile business analysis

View more presentations from Dennis Stevens.
Categories: Companies

kanban and the perfect job

Dennis Stevens and Associates - Sun, 01/16/2011 - 22:55

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This is the 5th principle behind the Agile Manifesto. The way this often gets translated is “take the top 10% of developers – put them in a room – and get out of their way.” This is great for the small groups of people that can build teams of entirely top 10% developers.  The question is, what do the other 90% of organizations do?

I believe this is a little chicken and egg. Do we build projects around motivated individuals – or can we design the work environment so that we end up with motivated individuals to build projects around? In the book, Understanding and Managing Organizational Behavior (George, J. M., and Jones, G.R. (2005). Understanding and managing organizational behavior, (4th ed.). Upper Saddle River, NJ: Prentice Hall.) there is a chapter entitled “Creating a Motivating Work Setting”. This chapter discusses the models and research associated with answering this question.

The Job Characteristics Model

In the 1970’s Richard Hackman and Greg Oldham attempted to identify which job characteristics contribute to intrinsically motivating work and what the consequences of these characteristics are. The thought process is that, when employees are intrinsically motivated, good performance makes them feel good – so they strive to achieve at a a high level and good performance becomes self-reinforcing.  Their model, called the job characteristics model, identifies five core dimensions that affect intrinsic motivation:

  • Skill Variety: The extent a job requires an employee to use a number of different skills, abilities, or talents.
  • Task Identify: The extent a job involves performing a whole piece of work from beginning to end.
  • Task Significance: The extent a job has an impact on the lives and work of other people in or out of the organization.
  • Autonomy: The degree a job allows an employee the freedom and independence to schedule work and decide how to carry it out.
  • Feedback: The extent performing a job provides an employee with clear information about his or her effectiveness.

There has been significant research done around this model. It turns out that jobs that are high in these characteristics have the psychological effect of increasing the experienced meaningfulness of work, increasing the experienced responsibility for work outcomes, and increasing the knowledge of results. In return, these psychological states have a high correlation with the job outcomes of high intrinsic motivation, higher job satisfaction, lower absenteeism and turnover, and higher job performance.

This is exactly what we want, highly motivated individuals to build projects around. While the psychological states and the job outcomes are emergent outcomes that we can’t cause directly, Hackman and Oldham have shown that when we design jobs based on the job characteristics model we can improve the likelihood these psychological states and the resulting desirable job outcomes with emerge.

The Motivating Potential of Kanban

When implemented well, Kanban creates a work setting where the job design delivers on the five core dimensions of the job characteristics model.

  • Skill Variety: In Kanban, the team members are involved in the daily planning of their work, engage in discussions around how to get the work done, perform their specific work, and may swarm on other related work.
  • Task Identity: In Kanban, the entire focus is on the flow of work. The team members see the work flow from start to end.
  • Task Significance: One of the focuses of Kanban is to improve the lives of the team members themselves.  The focus on flow of value also helps the team understand how they are improving the the work of the customer and/or the people their organization.
  • Autonomy: Kanban allows teams to schedule their work through the pull mechanism. The self-organizing nature of the work also helps them decide how to care it out.
  • Feedback: Managing Cycle Times, explicitly tracking defects, and the rapid feedback cycles associated with the limited WIP create feedback on effectiveness at multiple levels.

Kanban inherently results in job design that improves intrinsic motivation and the resulting high levels of performance.

Kanban and the Perfect Job

Hackman’s and Oldham’s job characteristic model provides insight into how the work environment can increase job performance. We tend to focus on the benefits that Kanban delivers by improving the flow of work. In addition to improving the mechanics of flow, Kanban also has the potential to result in job designs that are high in all five job characteristic domains.  These result in psychological states that correlate with desirable job outcomes including higher job performance. 

There is a risk in implementing Kanban that we end up focusing on just the mechanics associated with the flow of work. Forgetting that software development is knowledge work would be problematic. But, by leveraging the work environment of a Kanban implementation we can create an intrinsically motivating work environment. Combing improved flow with an intrinsically motivated work environment results in a much more productive organization. Focus on the human and work environment aspects along with the benefits of flow when we implement Kanban to create the perfect job for team members.

Categories: Companies

Standing By My Agile Claims

Dennis Stevens and Associates - Thu, 11/25/2010 - 17:27

I recently posted a presentation, Agile Foundations and Agile Myths, at www.slideshare.net/dennisstevens. My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

  • Standardize processes
  • Optimize resource utilization
  • Perform rigorous up-front design
  • Produce comprehensive documentation
  • Get up front commitment to a definitive Scope, Cost and Schedule
  • Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

  • linear-document driven "over the wall" process thinking
  • assigning resources to multiple projects
  • comprehensive upfront design with detailed documentation
  • commitment to definitive scope, cost, and schedule, and
  • strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

  • No Planning
  • No Documentation
  • No Estimating or Commitments
  • No Process
  • No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

Categories: Companies

Good Project, Bad Project

Ative at Work - Wed, 08/11/2010 - 13:42
The secret to writing good automated tests is to be a good software designer.

It sounds trivial - but the sad fact is that more often than not the attempt to implement test automation falls due to poor software design where people are struggling with strong dependencies where you cannot test a single class or module without also configuring a whole environment of databases, webservices, populating whatever tables etc.

When the novice experiences this the natural, but incorrect reaction, is to write fewer and fewer tests at a higher and higher level of integration, the limit case being manual end-to-end integration testing through the GUI.

It is a symptom of bad software design, not automated testing being worthless.

In a good project the test suite does not need to be changed when external data changes. In a bad project, the test suite breaks when time passes or every time someone runs the end-of-month job to add interest to the accounts, or when the ticker price changes for a stock.

In a good project, only a few localized changes to tests and production code are needed as for a requirement change. In a bad project, there is impact analysis and lots of similar changes all over the code-base to accomplish this.

In a good project most of the code does not know from where it gets its data - in a bad project, even a simple interest calculation business rule knows about how to look up the database and the interest rate web service.

In a good project there is typically 1-2x as much test code as production code. In a bad project there is often 5x-25x as much production code as test code.

In a good project most tests exercise only a single class or a few functions. In a bad project every tests activates a code-path through many parts and tiers of the application.

In a good project most of the test code is asserting that things went as expected. In a bad project, most of the test code is setting up the environment to run the test.

In a good project there are tests at all levels of the application. In a bad project they are mostly through the UI and often even manual.

In a good project you can change the application without risk. In a bad project change is painful, infrequent, risky and requires executive sign-off.

In a good project you can deploy new code to production safely many times a day. In a bad project you only do it reluctantly every monthly or a few times a year.
Categories: Companies

Tweetable Code - Introducing Docjure for Succintly Reading and Writing Spreadsheets

Ative at Work - Fri, 07/30/2010 - 16:08

How would you like to be able to SMS or tweet your Excel data-crunching code?

With Docjure, it is possible:

(->> (load-workbook "spreadsheet.xlsx")
     (select-sheet "Price List")
     (select-columns {:A :name, :B :price}))

This reads the A and B columns from the Price List sheet in the spreadsheet.xlsx file into a list of maps where the a column has key :name and the B column has key :price.

I believe that is pretty good for code small enough to fit in an SMS.

Exporting your business data to spreadsheets for further analysis is just as easy:

;; Create a spreadsheet and save it
(let [wb (create-workbook "Price List"
                          [["Name" "Price"]
                           ["Foo Widget" 100]
                           ["Bar Widget" 200]])
      sheet (select-sheet "Price List" wb)
      header-row (first (row-seq sheet))]
  (do
    (set-row-style! header-row (create-cell-style! wb {:background :yellow,
                                                       :font {:bold true}}))
    (save-workbook! "spreadsheet.xlsx" wb)))

In just a few lines of code and you have exported the price list to a worksheet, complete with a yellow-background bold header line for extra style points.

In our business applications, bridging to Excel has provided huge benefits:

  • Users love it - having their data in Excel enables them to do much more than a static report that can only be changed by a software developer.
  • Developers love it - It eliminates a lot of tedious code for generating bespoke reports as we can easily export data into an Excel report template.
  • Project managers love it - using spreadsheets provides an easy to understand data exchange format and the flexibility to change reporting features quickly late in the project.
  • Sponsors love it - the project saves a lot of time and reduces training cost by leveraging an application the users already know.

As an inspiration, here are some of the things we have used it for:

  • Use Excel to calculate currency trading strategies - the traders calculate their currency trading strategies in Excel then import it into the trading system. They benefit from the flexibility of a powerful tool they already know and the trading system takes care of the technical details of the actual trades.
  • Exporting to Excel for bespoke analysis - would you like to check your currency trading record? Export all the information to Excel and the traders can slice-and-dice it easily with little or no technical assitance. This is much easier than setting up a reporting database for them to link to.
  • Using Excel sheets for content management to facilitate translation - translating an application to all the languages of an international enterprise was easy. Rather than using complex technical XML-files we made Excel sheets the data format for the application strings and had the subsidiaries add their translations to that. Then we put an adapter on the application to convert back and forth to XML-config files and RESX files used internally in the web and Silverlight parts of the application. The translators had a great experience, they had a familiar tool with spell checking and it reduced waste in the translation process by presenting a well-known easily accessible format.
  • Exporting to Excel for reporting - set up a spreadsheet template with a data sheet and some reports based on that, then populate it with data from your application. This allows the users to easily change or add reports with no change to the software application itself, thus dramatically reducing the turn-around time for new reports. 

We believe this is so great that we just have to share it:

Therefore, Docjure is free and open-source.

It is written in Clojure for the JVM. Get it at our GitHub page here: http://github.com/ative/docjure and be sure to follow our updates on Twitter: @ativedk (http://twitter.com/ativedk)

Categories: Companies

Psst...Scrumy has an API now

Scrumy Blog - Thu, 07/01/2010 - 07:00

It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.

For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.

The Scrumy API is divided into two separate parts: REST and Webhooks.

The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.

Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.

So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at support@scrumy.com.

Categories: Companies