Archive | sdlc RSS feed for this section

Strategies for Scaling Agile Development

Towards agile architecture
Architecture throughout the lifecycle
Who is responsible for architecture?
Have an “architecture owner” role
Agile architecture at scale
Base your architecture on requirements
Model your architecture
Consider several alternatives
Remember enterprise constraints
Travel light
Prove your architecture with working code
Communicate your architecture 
Think about the future, just wait to act (defer commitment)
Take a multi-view approach
How does this work?
Who is actually doing this?
Addressing the myths around agile and architecture

(Full Story: Strategies for Scaling Agile Development)

Strategies for Scaling Agile Development

  1. Towards agile architecture
  2. Architecture throughout the lifecycle
  3. Who is responsible for architecture?
  4. Have an “architecture owner” role
  5. Agile architecture at scale
  6. Base your architecture on requirements
  7. Model your architecture
  8. Consider several alternatives
  9. Remember enterprise constraints
  10. Travel light
  11. Prove your architecture with working code
  12. Communicate your architecture
  13. Think about the future, just wait to act (defer commitment)
  14. Take a multi-view approach
  15. How does this work?
  16. Who is actually doing this?
  17. Addressing the myths around agile and architecture

(Full Story: Strategies for Scaling Agile Development)

XP QoW: Responsibility is accepted, not given

The third in my series of quotes from Extreme Programming Explained: Embrace Change by Kent Beck. Once a week I post a quote from XP that I think is really important to consider when developing software. This is from the end of Chapter 8:

Accepted Responsibility-No single action takes the life out of a team or a person more than being told what to do, especially if the job is clearly impossible. Primate dominance displays work only so long in getting people to act like they are going along. Along the way, a person told what to do will find a thousand ways of expressing their frustration, most of the them to the detriment of the team and many of them to the detriment on the person.

The alternative is that responsibility be accepted, not given. This does not mean that you always do exactly what you feel like doing. You are part of a team, and if the team comes to the conclusion that a certain task needs doing, someone will choose to do it, no matter how odious.”

There are two key things to listen to in this excerpt. First always work with your direct reports to define, estimate and plan their work. If they have helped craft the goal they will feel much more ownership toward completing on-time and at high quality. Secondly, if you have buy-in from everyone on the team then they will want to do everything needed to complete the project.

The job of the manager is to pick the destination and make sure everyone is rowing towards. Everything else is up to the team.

Looks for more XP Quotes of the Week to be forthcoming.

Past quotes:

XP QoW: Assume Simplicity

The second in my series of quotes from Extreme Programming Explained: Embrace Change by Kent Beck. Once a week I post a quote from XP that I think is really important to consider when developing software. This is from the second page of Chapter 8:

Assume simplicity-Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%. In many ways, this is the hardest principle for programmers to swallow. We are traditionally told to plan for the future, to design for reuse. Instead, XP says to do a  good job (tests, refactoring, communication) of solving today’s job today and trust your ability to add complexity in the future where you need it. The economics of software favor this approach.”

Two guys built Twitter in two weeks.

Looks for more XP Quotes of the Week to be forthcoming.

Past quotes:

XP QoW: The Customers get to Pick 3

I recently got around to reading Extreme Programming Explained: Embrace Change by Kent Beck. My wife had gotten it for me a year or two ago when she read a recommendation on Bram Cohen’s blog.  Bram is most notable for creating BitTorrent he recommedned the XP book, Peopleware and Non-Manipulative Selling.

Since it’s publishing in 2000 this book has caused a good amount of change in the software industry in the take of agile processes and adding things like Continuous Integration to traditional waterfall projects.

Once a week I’m going to post a quote from XP that I think is really important to consider when developing software.  The first is from the beginning of Chapter 4:

“…there are four variables in software development”

  • Cost
  • Time
  • Quality
  • Scope

 The way the software development game is played in this model is that external forces (customers, managers) get to pick the values of any three of the variables.  The development team gets to pick the resultant value of the fourth variable.”

Every project and development manager should read this full chapter before planning a project.  it’s only 5 pages so it only takes a few minutes.

Looks for more XP Quotes of the Week to be forthcoming.

Closing a Few Doors: Software Requirements Gathering

Wow, the parallels in Dr. Ariely new book “Predictably Irrational” to the Software Requirments Gathering process are unintentional but powerful.

“Xiang Yu was a Chinese general in the third century B.C. who took his troops across the Yangtze River into enemy territory and performed an experiment in decision making. He crushed his troops’ cooking pots and burned their ships.

He explained this was to focus them on moving forward — a motivational speech that was not appreciated by many of the soldiers watching their retreat option go up in flames. But General Xiang Yu would be vindicated, both on the battlefield and in the annals of social science research.

He is one of the role models in Dan Ariely’s new book, “Predictably Irrational,” an entertaining look at human foibles like the penchant for keeping too many options open. General Xiang Yu was a rare exception to the norm, a warrior who conquered by being unpredictably rational.

Most people can’t make such a painful choice, not even the students at a bastion of rationality like the Massachusetts Institute of Technology, where Dr. Ariely is a professor of behavioral economics. In a series of experiments, hundreds of students could not bear to let their options vanish, even though it was obviously a dumb strategy (and they weren’t even asked to burn anything).

The experiments involved a game that eliminated the excuses we usually have for refusing to let go.. In the real world, we can always tell ourselves that it’s good to keep options open.

You don’t even know how a camera’s burst-mode flash works, but you persuade yourself to pay for the extra feature just in case. You no longer have anything in common with someone who keeps calling you, but you hate to just zap the relationship.”

How many of us have fought business analysts who want ‘everything configurable’ and to deploy ‘every feature’? Frankly, I can’t think of any bigger timesink for software teams these days.

See the full article and NYT review at: The Advantages of Closing a Few Doors – New York Times


Follow

Get every new post delivered to your Inbox.