Agile Fundamentals: The Feedback Loop

Dietrich Kappe, Tuesday, June 23, 2009 @ 2:28 pm

When you improve a little each day, eventually big things occur. -- John Wooden

photo credit: mister b 1138

A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted -- that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.

Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don't like it.

These [thirteen] practices support one another...and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:

1. Feedback loop
2. Feedback loop
3. Feedback loop

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Effective vs Efficient Teams

Michael Walkden, Thursday, June 4, 2009 @ 6:59 am

We hear more and more about large organizations adopting Agile software development practices recently.  This is not surprising given that Agile practices have many advantages over traditional methods.  One significant difference with Agile is the focus on building good teams.  Unfortunately organizations new to Agile often miss two fundamental questions before jumping into an Agile adoption.  The questions are deeply related, but not directly at first.

1. Why do Agile? To put it simply: Software projects can be better, faster, or cheaper by using Agile practices.  Pick any, and only, two.
2. What kind of team should be created?  Efficient or effective?

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

software development

Avoid the last minute security review

John McCaffrey, Wednesday, May 13, 2009 @ 4:10 am

Photo Credit:
Amagill under Creative Commons Attribution

Security is hard

Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.

Oh, and if the code base isn't sufficiently tested, you're in for a world of hurt.

If you are a developer that was just asked to 'do a quick security check and plug any holes', you are now in the difficult position of managing the expectation that a two-week security review means "we're covered". Be realistic about what you can accomplish, setting out some short-term and long-term goals.

Do More With Less. Start with a research 'Spike'

Instead of pushing for more time to be able to 'cover it all' (even though you have no idea what 'it all' is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I've found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.

Plan for success

With your analysis and recommendations in hand,
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Bugs can’t be estimated

John McCaffrey, Tuesday, May 5, 2009 @ 11:37 pm

In an earlier post about the benefits of Agile and Scrum, I made a statement that bugs by their nature are not the same as normal features, and I wanted to take a moment to try and make my point a little clearer. Bugs and estimation have been a hot topic with us lately, but interestingly we are all working on different projects and actually have a slightly different take on the subject.

My definition of a bug is: A feature that was specified, and you attempted to deliver, but is not working according to your intentions. (ie. "I thought it WAS saving to the database")

Not a bug: A feature or variation that you hadn't intended to create in the first place. ("Oh, I didn't know it was supposed to do that when you clicked the back button")

And with that understanding I say "Bugs can't be estimated"
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

Are You Building an Application or an Antique Web Framework?

Dietrich Kappe, Tuesday, May 5, 2009 @ 5:47 pm

photo credit: dave_7

A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.

My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It's actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Writing Agile Requirements

Bernhard Kappe, Monday, April 13, 2009 @ 7:48 am

The beginning of a project generates a lot of great ideas. But until a structure or cohesion is applied to these ideas, they end up being a loose collection of separate ideas with no direction. Writing agile requirements brings cohesion and direction to the noise. We've been continually improving user driven agile for a while now. Click through the presentation below to see the approach that works for us.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Adopt a non-techie. Help your business team move faster

John McCaffrey, Wednesday, April 8, 2009 @ 4:00 am

I've been spending some time with our internal sales and marketing team to hash out some of our goals for the year, and it became quite clear to me that non-developers are on their computers all day long facing some of the same technical challenges we do.

Some of the tasks they have to do:

• "take the data out of the spreadsheet for last quarter and compare it to this quarter"
• "gather the bounced emails from our newsletter posting, and update our list, pulling out duplicates"
• "replace all the names and addresses from our NDA agreement each time it is sent to a new client"
• "slice and dice google ad-words and google analytics data"

So I've resolved to take some time each week to 'Adopt a non-techie', and help them spend less time 'screwing around with the computer' and more time on the most valuable tasks they do.

In the same way that developers need to be as efficient as possible with the tools they use, Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Before your Code Mildews — Refactor!

Karega Scott, Tuesday, April 7, 2009 @ 8:52 am

photo credit: erix!

In my last post, See the Code, Be the Code, I compared agile development to the game of golf. But how does one truly "see the code" as the software grows in size and complexity? On one hand, you could ignore the fact that software is developed over many iterations and try to build a very complex system all at once that does everything under the sun, or you can keep the design simple and focus on the iteration at hand knowing that as our understanding increases we will refactor the code.

Refactoring is the process by which you modify the behavior and appearance of the code to ensure that code is up-to-date with current system requirements or changes in the system environment. It gives the development team an opportunity to continuously improve code quality for long term readability and maintainability. The easier the code is to follow, the less time it will take for current and future development teams to make changes as the system matures. It can also help the development team take advantages of improvements to existing frameworks and other software used to develop the application. These improvements can be realized through better performance and reusability of existing and future code. In short, it helps keep your code from become stale and mildewy.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Pairing Remotely for Fun and Profit

Jason Pearl, Tuesday, March 17, 2009 @ 6:30 am

Love it or hate it, pair programming is a large component of many agile development methodologies.  I've become a firm believer in the benefits of pairing, and very rarely write code nowadays without some degree of collaboration with a second (or third) developer.  The benefits have been vast.  The code is better thought out because a pairing session always starts with a discussion of the approach to be taken.  Fat-fingered mistakes are headed off at the pass because a second set of eyes is closely watching what's being typed.  Less time is wasted checking email, taking calls from the in-laws, and just generally doing things that would annoy the second member of the pair.  Above all, it allows developers to analyze and quickly debate the approach being taken,  and adjust and improve that approach throughout the development cycle.

It all sounds great doesn't it?  Well it is when executed correctly.  In my experience there are two general principals that if not adhered to, will turn a productive pairing session into a developer writing some mediocre code sitting next to a developer who might as well have taken the day off.   These principals are: developers must remain engaged, and developers like their own space.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Week in Review

Dietrich Kappe, Sunday, March 15, 2009 @ 6:56 pm

Some interesting posts from around the blogosphere:

• The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
• InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
• UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
• David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it's a question that comes up often and is worth thinking about.
• A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better. But seriously, we don't have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).

These were some of the posts that I found valuable over the last week. Please share yours in the comments.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Scrum defined in under 10 minutes

John McCaffrey, Thursday, January 22, 2009 @ 4:26 pm

Hamid Shojaee from www.axosoft.com put together a great video to introduce the core concepts of scrum and Agile practices called "Scrum in under 10 minutes"

I really like what he said particularly the focus on the importance and simplicity of the burndown chart which helps to :

• Visually show the hours remaining, and help anyone see "are we there yet?"

• Allows decision-makers to make adjustments if needed

A simple burndown chart quickly shows the impact of some of the most common efficiency killers or blockers

1.    late-breaking requirements changes
2.    waiting for business decision
3.    waiting for tech. partner (ssl keys, ops. vendor, etc)

He mentioned the standup, but didn't cover the 3 questions (What did you do?, What are you going to do? What do you Need in order to accomplish it?), or the idea that only people that have work can speak (Chickens vs. pigs)

I also liked his take on bugs, that you should plan a sprint to tackle them, and any bugs that come up during a sprint should be tackled immediately.

That's actually something that a lot of teams struggle with, "How do you plan for and estimate the time necessary to fix bugs?"

I always say Bugs Can't be estimated. While you may be able to plan how much time you will allocate to working on bugs, you can't really estimate how long it will take to fix bugs unless you have already looked at them, and have figured out the problem. From my point of view its the "looking at it and figuring out what's wrong", that takes the longest, and is the part that needs to be accounted for.

How do you plan for bugs?
Do you let bugs accumulate and then have a final sprint before a Release where you tackle all of the bugs? (How would you know that you can fix all the bugs in time for the release?)

Do you tackle all High-Priority bugs as soon as they come up, and leave the medium and small priority bugs for later?

Do you have a 'zero-bug' policy, where you fix any bugs that are opened?

UPDATE: I've expanded on this discussion a little more in a new post Bugs Can't be estimated, and after having some discussions around how best to plan for bugs, I was asked to do a last minute Security Analysis, and I wrote a post about How to avoid the last minute security review, and I think that the planning part can actually apply to how you manage a big list of bugs as well.

• Digg
• Reddit
• del.icio.us

Comments (4)

agile ajax

Escaping the Iterative Development Trap

Josh Symonds, Monday, January 19, 2009 @ 11:44 pm

While designing software it's easy to fall into the trap of iterative development. Iterative development allows us to work quickly, exchanging rigorous requirements-gathering for rapid design and development -- and as good developers, it is our responsibility to make sure that the code we create now works well with future iterations of our program. However, I find that code created as part of this process can frequently be too complicated, too generalized, or both. When creating agile software we must keep in mind the requirements of the future, but design strictly for the requirements of the present. If we are snared by the trap of iterative development, we risk wasting time, money, and people on code that may not be useful in the future -- or, even worse, code that the client doesn't want and can't use.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Continuous Integration Meets Risk-Based Testing

Ivan Moscoso, Thursday, December 18, 2008 @ 1:30 pm

A new version of TeamCity is out, and while I have not taken it for a ride yet, I found this feature particularly interesting:

Risk Group Tests, Tests Re-ordering
TeamCity 4.0 is now able to determine a set of tests which are likely to fail (i.e., recently modified, those with frequent failures history, etc.), and perform those tests first the next time the project builds. This allows teams to confirm potential fixes sooner, reducing feedback time.

There are strong cases to be made for risk-based testing in certain environments. The reason why it is not more commonplace is that implementation is tricky since it requires the CI system to know a few things which are hard to generalize:

• The type of build and testing framework
• Historical perspective across multiple builds
• A good set of heuristics along the way

Since a risk-based approach may mean skipping certain tests on some builds, this may sound like a step backwards to the agile developer. But consider it an alternative to improving overall build time (i.e. "based on very low risk assessment, tests which never failed will not be run every time."). The hard part is defining what "low risk" means to your project, and how much value you would get reducing overall build time.

This is obviously not an issue on well-run projects with sub-minute builds, but if you were to be dropped into an existing project with, say, a large code base and a fifty-two minute build (I've seen it), this can become one way to perform triage on an otherwise untenable position. You don't need a new CI system to implement risk-based testing, but having this alternative can't hurt.

• Digg
• Reddit
• del.icio.us

Comments (0)

software development

iPhone SDK: UIViewController Testing & TDD

Ivan Moscoso, Tuesday, November 18, 2008 @ 11:47 pm

Unfortunately there are not enough examples out there on how to test view controllers with the iPhone SDK. My hope is to remedy that a bit by sharing some techniques I have been using to tackle the problem, particularly in keeping with the spirit of TDD along the way.

First, If you have not already done so, configure your project to use GTM. This is a bit of a no-brainer as it currently stands. Until Apple comes up with something better, GTM is the way to go. It works as advertised, and is a credit to the folks at Google for providing this toolkit.

Now then, many tutorials on the web seem to imply that one should test somewhere in the middle by suggesting to add a few outlets to your controller, fire up IB and wire up your view to your view controller before you even start to think about testing any of it.

Testing controller logic means working under the assumption that you have wired up your view components correctly to match the controller's actions and outlets. Wire up an element to the wrong action (or worse, forget to wire it up at all) and you can easily learn to rely too heavily on manual testing. While this might be acceptable for small one-off applications, within a team of developers practicing collective code ownership, this kind of error can cost real money over time. "Thanks for caring, but I'd rather have a unit test."

Now then, let's take a look at some code!

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

agile ajax

What makes a good requirement document for an agile project

Jason Sendelbach, Thursday, November 6, 2008 @ 12:26 pm

As a developer, I start from requirements. I have worn project management and business analyst 'hats' on many projects (but I am a geek, as I really enjoy the developer hat the most). My coworker, Alice Toth, has come up with a pretty awesome template and style of writing requirements that seems to be perfect for the agile development methodology. Too often, I see struggling projects struggle, because their requirements suck. I look at their "requirements" and they are nothing more than a picture with a bunch of notes. The developers have so many questions, and in general, all people involved (client, developers, BAs, IAs and testers) don't have a good understanding of the system as a whole, and what are the various personas that use the system.

I have worked on projects that have used Use Cases and Functional Specifications, but these never seem to convey all the necessary information for all involved. They tend to be very verbose, and they are really not fun to write, read or manage. A good requirement should tell each audience member exactly what the expected functionality is, and never generate a myriad of questions from all involved. It's often difficult to solicit information from a client, but documenting for developers should never be that hard. Here is a recap of what a good requirement is:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax