Posts tagged as:

process

Andy Hunt is the author or co-author of several programming books including:

  • The Pragmatic Programmer
  • Programming Ruby (the Pickaxe book)
  • Pragmatic Unit testing in C# with Nunit
  • Practices of an Agile Developer
  • Pragmatic Thinking and Learning: Refactor Your Wetware

He’s also one of the original signatories of the Agile Manifesto.

Andy is a great person to talk about regarding Agile Development. Here are some things he says you need to become agile and where to start:

  • Do a little of the right things all the time
  • You’ll be the expert on the project at the end of the project. Defer important decisions until you understand the problem.
  • Stand up meetings
  • Set ground rules
  • Make sure you have a stable build environment and version control
  • Unit Tests
  • Continuous Integration
  • Code Reviews/Pair Programming – Check the code
  • Involve the Customer
  • Produce something every 1-4 weeks
  • Retrospectives – Get Feedback

Download this Episode

{ 2 comments }

Asking people what Agile development is is like asking people what math is. You could get answers varying from specific operations to branches of math like algebra or calculus. The answers the Agile question vary from specific practices of certain Agile methodologies like pair programming, standing meetings, sprints, and sprint boards to ‘not waterfall.’

The real answer depends on which question you’re trying to answer. “What is Agile?” usually translates to one of the following.

  • What is at the core of Agile development?
  • What is the purpose of Agile development? What is it trying to solve?
  • How do I implement Agile development?

Let’s dig into these questions.

What is at the core of Agile development?

The traditional core of Agile development is the Agile Manifesto. The Agile Manifesto states:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes 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.

I wrote a post over at the Business is Pleasure blog on where agile methodologies break down. The post also covers the general principles behind agile development. Since I don’t want to duplicate content, I’ll summarize here.

In general, the focus of the Agile Manifesto is basically to:

  • allow people to excel according to their strengths, rather than according to the system.
  • make sure software works, rather than get caught up in documenting what it should do.
  • make the software usable.
  • involve the end user and business people before you march too far down the wrong road
  • adapt to changes—after all, we’re dealing with real life, here.

What is the purpose of Agile development? What is it trying to solve?

Most Agile proponents would answer this question by explaining the Waterfall method. However, I think the supposed anti-pattern that the Waterfall method represents distracts from the point of Agile development rather than defining it.

Agile development is really about providing a framework that allows developers to build something useful for real world users and deal with the realities of interruptions, timelines, and technical requirements that disrupt an ideal development cycle. In other words, Agile development helps developers deal with reality.

Certain practices, such as iterations, pair programming, code reviews, and retrospectives help developers and development teams adapt to change, avoid or fix bugs, and find ways to employ their strengths to build great software.

Let’s face it, if a programmer or team knew what the ideal product was when they started coding and could work uninterrupted until they were done, they would get pretty close to the ideal product. However, product development never works this smoothly. Typically, a prototype is developed, shown to a few users, taken back to the drawing board to be molded into a better prototype, over and over again until a prototype appears that is good enough to be called a ‘product.’ We then stamp a version number on it and ship it.

Agile helps us deal with these types of interruptions and reworks that are part of the reality of building software.

How do I implement Agile development?

This is where the things get crazy. Everyone seems to have a horse in this race. The Extreme Programming (XP) people think they have the ultimate way to build software. The Scrum folks think the XP folks have missed the point in some aspects. The big name agile coaches and book publishers want you to follow methodologies that benefit them.

So, what is the right way to go? A lot of people will tell you a lot of things. The one thing that many people won’t tell you is “Do what works for you.”

Agile development’s first tenet according to the Agile Manifesto is:

Individuals and interactions over processes and tools

This tells me to do what makes for the most effective interactions and individuals. This implies that you know your strengths. If you don’t, don’t worry. You’ll figure it out as you go.

I recommend to most people that they look into XP, Scrum, or some other Agile methodology they’ve heard of. Choose one or two of their practices and try them out. A good try will occur over a few months. If they don’t work after you’ve gotten used to them, find ways to modify them so you can get the benefits from them and minimize the problems you’re having. Or stop them altogether.

The Agile methodologies are a good roadmap for solving your programming process’ problems, but they are not the destination. The destination is great code. The practices behind Agile methodologies can show you the roads to get you there faster.

I’ve never met anyone who had 100% adherence to a particular methodology work for them. But I’ve seen people get close and get results.

Conclusion

Overall, the confusion about Agile development comes from one of its strengths. You define how Agile works for you. It’s similar to the principles of good living that most people get from their religion. There’s a huge amount of overlap in the religions out there, you just have to find what you believe to be truth and then do your best.

{ 5 comments }

This year’s Agile Roots conference is focused on building great software. They have a terrific line up of speakers and it only costs $250, which makes it a great deal! The conference this year focuses on the development process and how it formulates requirements that lead to great software. Not just great software to maintain and build. But also great software that provides value to users.

Andrew explained that we, as developers, need to realize that we’re enabling a business experiment, not just building code.

He also went into the value we receive from open source software. The problem some of these people have is collecting the value of their work. You don’t get paid for being smart. Rather, we need to find ways to receive value from what we’re providing, even if it’s not designed specifically to make us money.

Pat Maddox wrote a blog post called “Are you punching your users in the face?” It was designed to help people to understand was that the value of the code isn’t in the tests or the code itself. Its value is in building software that users want to use.

We got a great recommendation to read “A Big Ball of Mud”. The author asked “What do you call someone who writes code like this?” after talking about every antipattern and code nastiness and he said “millionaires.” Historically this is true. Someone solved someone else’s problem with ugly hacky code, and walked away with millions of dollars.

We tend to discount sales and marketing personnel, when they are the ones that make your money. They build the brand and they bring the money in, even if you don’t have the best products.

Tim O’Reilly said, “Create more value than you capture.” If you do this your users will love you and your community will grow and support you.

We go into the idea economy and how agile ties into the idea economy. People are trying to sell each other on their ideas in agile as much as anything else.

Andrew was first introduced to Agile he found most of the practices as wasteful, painful, and wrong. So, he started discovering the roots of Agile. What he found was that Agile was bout solving our problems with our strengths. Once he started going to the Agile Round Table, he found that it was actually about delivering working software.

Over the last year and a half, Andrew has been working on taking agile into other areas of work.

The term ‘agile’ has become overloaded. Some people say agile, what most people mean is a watered down half implemented version of scrum.

Agile, the word, has crossed the chasm. The practices haven’t.

Trying to agile isn’t what you should do. You should be trying to be awesome.

Listen to the interview for some great tips on being awesome.

Here are some links to following Andrew:

Twitter: littleidea

Blog: http://stochasticresonance.wordpress.com/

Download this Episode

{ 0 comments }

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer.

He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community.

We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. [click to continue…]

{ 4 comments }

This week I interviewed Chad Fowler. He and several others have helped organize Ruby conferences around the world, most notably RailsConf, RubyConf, and RubyConf India. He has also written The Passionate Programmer and Rails Recipes. Finally, he has contributed to open source projects like RubyGems and Facebooker.
[click to continue…]

{ 1 comment }

Test Driven Development and Behavior Driven Development can be terrific tools in defining your code and ensuring the highest quailty software. In this episode, we discuss the differences between TDD and BDD and what the advantages are to doing them.

We also talk about these test tools:

Download this Episode

{ 2 comments }

In order to contribute as an employee or a freelance developer, we need to understand the nature of business. Specifically, we need to understand the nature of how our employer or client makes money so we understand our contribution and so we recognize where our value is.

Once we understand the nature of business, we can look for other pain points people are facing and find ways to solve those problems. That’s how we get paid.

[click to continue…]

{ 5 comments }

Download this episode

Subscribe in iTunes

Remember to leave feedback by calling 801-753-8279 or emailing podcast@railscoach.com.

Conferences are a great way to learn and meet people.

The conferences I’ve attended:

Tips for getting the most out of conferences:

[click to continue…]

{ 1 comment }

Download this episode

Why Another Rails Podcast?

Basically, many of us need someone who will encourage us and share our passion for what we do. This podcast is designed to help push you to become a better developer and to help you find people who are as crazy about programming as you are! Excellence and collaboration are the goal!

[click to continue…]

{ 0 comments }