Tag Archives: software development

Agile 2008

Posted on by

toronto_skyline
Steven Doc List and I held a 20 minute presentation and 60 minute open space on software ethics.

I think the format works. Software ethics is not rules or reason, it is navigating essential complexity in building software and in moral choice. Descriptions that “abstract away its complexity often abstract away its essence” (Fred Brooks)

We embrace essential complexity using the values and practices of agile software development.

We can become better software developers using the same tools we use to build better software.

We can learn through practice to recognize and accept responsibility for the intended benefit and unintended harm we create.

We can retrospect on our actions and their consequences, engage in a conversation with our peers, learn from, challenge, and support each other.

Don’t Justify Agile Based on Productivity (revisit)

Posted on by

Kallokain wrote a rebuttal to my post questioning the value of productivity metrics to justify agile.

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers.
I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. (read the post)

Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven’t seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect.

In my experience, measures that are tied to some non-revenue related abstract concept of “productivity” such as lines of code, story points, etc. are more problematic than helpful.

My point about velocity is that it is a measure that should be a feedback system back to the teams and becomes problematic if it is considered some sort of intrinsically meaningful measure that can be reported to senior executives (as in “We completed 20 story points last iteration, 25 this iteration. We’re five story points more efficient!”)

I agree that the ultimate measure of success in business is profit. I understand that any business decision should somehow influence revenue gains or hard dollar cost savings.

The problem with justifying an agile adoption based on revenue gains is there are so many other considerations that attempts to credit any single factor become dubious.

Cost savings need to be real not theoretical. Who did you lay off? How much budget did you give back based on agile adoption? Jeff Sutherland has a paper that does show significant cost savings using Scrum. The subject company was a CMMI-5 organization and there commitment and rigor to measurement was higher than most companies would support and is cost justified based on the government regulations they perform under.

If someone can propose a relevant metric that is economical for a small to medium size business to collect, that can be measured over time in small enough units to show increased performance due to specific process changes, that has some relation to reality that can be meaningfully communicated to senior managers, and doesn’t create more problems than it solves, I will be happy to consider it.

Microsoft and Ript

Posted on by

Gerry spoke at the Microsoft Women’s Conference this week.

Ript

I joined her so that we could meet with some key players at Microsoft to talk about Ript™, our WPF application.

Attending were Henry Hahn, WPF Program Manager, Darren Mc Cormick, Worldwide UX Role Owner, and Katherine Westgate, a Marketing Officer from Microsoft’s NY office.

The conversation ranged over the whole history of our project: our Scrum/XP practices, how our team collaborates on user experience, how we created our product vision and our plan to monetize the product.

The three of them were entirely approachable, engaged and enthusiastic. They also came prepared. They’d all downloaded and worked with our application. Henry actually submitted feature suggestions from his team he knows are easy to implement given what we’ve already created.

Katherine helped pull the attendees together and lined up our hands on demo of Surface™. She was interested in figuring how our experiences with Ript™, agile software development and collaborative product ownership might help her enterprise clients. She also asked Gerry how Oxygen approaches advocacy for women, corporate good will and citizenship. Katherine is sharp and conscientious. I could tell Gerry hit it off with her.

Darren described the Developer Platform Evangelists (DPE) programs for joint marketing and developer assistance around products built in WPF and Silverlight. We discussed some of Microsoft’s goals for Silverlight distribution and what Oxygen’s next steps are to engage these resources. Darren is clearly passionate about user experience at the level of product, brand and within an organization. Yet another example of Microsoft going outside its organization to bring in new thinking.

Gerry’s main points were that women are the principle market for consumer technology, that usability testing with women provides valuable insight, how software should playful, purposeful, simple and accessible and how product development should not focus on early adopters but the people who will make up the vast majority of end users should the product be successful.

The conversation also ranged over tech issues. Henry is a fan of our application and left an open door for further communication. He said the .NET team is working on some of our core concerns:

  • breaking up the .NET 3 installer into server and client modules making the package smaller
  • improving the experience of their default install (it plays out like a windows update, hiding itself in the system tray – this is very confusing in an application install process)
  • making it easier for ISV’s to run a silent install and wrap their own UI around the install
  • improving cold start time
  • providing more expressive API’s for automated UI testing

Don’t expect any of this soon unfortunately.

Clearly there are employees at Microsoft in leadership roles determined to engage with and support, not simply consume, innovative work originating outside the company. I had the same impression at the ALT.NET conference earlier this month.

This bodes well for both Microsoft’s future as well as for those of us looking to innovate in the marketplace using their tools and platforms.

Team

Posted on by

At Oxygen, we have a team. Knot

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

The Oxygen Team

Scrum without XP?

Posted on by

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Oxygen Standup

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.