Tag: agile

Don’t Give me Rework Refusal!

Over the last few weeks I’ve seen a few comments regarding rework. One of those comments was Julie Booth’s (@uxsuccess) comment on Twitter regarding rework,

“Do not fear rework!!”

That kicked me off with a response of,

“Do not fear rework!! /via @uxsuccess so true, plz plz don’t cower before rework!!! :). Listen to @uxsuccess!“

Then just recently I stumbled onto a book I’ve been meaning to read called Rework.  This book is written by the crew at 37signals.  This company is best known for SaaS Offerings Basecamp, Highrise, Campfire, and Backpack.  All of them created with high quality, solid UX (User eXperience), probably great code quality, maintainability, and the list of goodness goes on.  In addition, the other thing that 37signals is widely known for is their efforts around Ruby on Rails (created by DHH @dhh).

Rework is a fundamental requirement to actually getting an elegant solution.  It might seem chaotic or disconnected at first, but it quickly becomes a vastly superior way of doing things instead of the “Do it once, do it right the first time” nonsense.  Things need to change, doing things right the first time is almost impossible anyway.  That is why you practice playing guitar before becoming a virtuoso, you learn to hammer before becoming a carpenter, you sketch and draw before becoming an architect, and the list goes on.

Don’t expect perfection, expect creation.  That’s what I’d say.  If you can’t tell, I agree with the Ruby on Rails mindset, with a lot of what DHH/@dhh writes, and I especially respect what 37signals has accomplished and the revolutionary business ideas in the book Rework.

These types of ideas – simple rework and the open minded approach to rework – makes a business faster, more agile, and responsive to their customers’ needs.  These ideas, these mentalities are what have created great companies in the past and will build great companies in the future.  The companies that suffer the traditional approaches and mindsets are at significant risk of being eliminated from the market altogether.

There are many others out there also, that push these types of ideas and mentalities around rework, refactoring, and agile practices.  If you haven’t checked out who 37signals is, the book Rework, or Ruby on Rails you should stop whatever you’re doing and find out about this company and its products.  Especially find out how their products were built with business agility in mind, with a strong dose of Agile ideals.  With that I bid adieu for the day.  Happy coding, and don’t fear the rework.

It Brought a Tear to My Eye, Agile Ideals Rock!

I’ve been leading a software development project for a little over a month, one of my team members and I have been communicating back and forth steadily.  Via IM or verbally, e-mail or however we need to.  We’re having a good time figuring out things as they come and getting things done in a very Agile way.  To lay it out as the manifesto is written;

We keep ourselves and interactions over process and tools.  We make sure to have working software on almost every single build that could literally be deployed, while forgoing the currently unnecessary documentation.  We collaborate constantly with the customer representative and don’t worry every minute about the contract negotiation.  Response to change is almost instant, as it comes along almost every day.

As we’re hustling along getting a complete vertical implementation of a project together this coworker comes to me and states, “It is great to work on a project with someone that knows what they’re doing, and not sent off in a corner to read documentation books on what was done in the past!”  That statement made me so happy.  This is one of the major reasons I advocate Agile!

Agile helps team members get bought into the project.  The team gets involved in ways that other processes just don’t allow.  The team feels enabled, empowered, or whatever one may call it to actually get the job done!  Being Agile isn’t about process or tasks or work items, being Agile is a mindset, is about being interested and involved in what you’re doing for your project.

After a dirge of conversations and some frustrating efforts recently, this is the type of thing that leaves those negatives in the dust.  This is the type of statement and motivation, when I see it, that makes me love what I do and love to come into the office each day!

So anyway, I had to make this post.  Because today, even though I thought it would be a slightly miserable day.  That one statement redeemed it and my day is now rocking!

August 2010 Agile Beer, SAWSUG, and Hadoop in Seattle

I should come up with an entertaining title for these blog entries about the Seattle Tech Scene.  But that’s for another time, right now I’m going to focus on the events of this last week.

Agile Beer

I guess there is a bit of a history behind Agile Beer, but I wasn’t aware of it when I decided to go to an impromptu Agile Beer Meet Up @ Elysian Brewing on Capital Hill.  At peak there were 7 of us, having a good time chatting about various aspects of Agile.  Next meet up, we’d love to see more people.  This is also were someone could possibly help me out – who exactly organizes Agile Beer, and is there an official shindig related to this?  When I do a Google/Bing Search with just “Agile Beer Seattle” I get a couple different sources of information, but most of it looks like nothing is really going on.  Any word on this?  Anybody?

Amazon Web Services
Amazon Web Services

Seattle AWS User Group (www.sawsug.com)

The Seattle AWS User Group is pretty cool.  This meet we had Jeff Barr (AWS Evangelist) and Jenn Boden (Director of Corporate IT) speak on one of the new security white papers released and general topics.  Jeff & Jenn are pros when it comes to answering the hard ball questions.

The second phase of topics included a talk on Virtual Private Cloud Architecture and another on Multizone RDS.

Hadoop
Hadoop

Hadoop Seattle

The Seattle Hadoop Meet, as usual, rocked too.  I love hearing about the Hadoop and Hadoop related topics.  The big data problem always has a host of, what I consider, very interesting solutions.

Waterfall vs. Agile

Before reading this you should know what the Agile Manifesto is and the Agile Principles are.

I’ve seen it on more than one project in my career and it always seems to happen.  Agile rarely gets credit in this scenario.  People rarely learn what was and was not effective on the project in this scenario.  Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know.  What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.

The scenario generally starts like this…

A project is green-lighted for whatever reason.  Often with some high level manager determining that a project will save or make $X amount of money.  The project is poorly defined or simply not defined at all.  The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management.  There are at least a half dozen external dependencies the project must have completed.  (Take Note Upper Management & Executives:  Six Sigma/Lean Processes can help at this level dramatically)

Waterfall Approach

In a waterfall approach all of these things will have to be documented and nothing initially gets developed.  The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with.  In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation.  To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software.  A 6th grader would study this and say, “so they write a bunch of lies right?”

When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start.  Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down.  Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.

Agile Approach

An Agile approach on the other hand would start finding the clients and consumers of the theoretical software.  These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created.  Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do.  The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated.  Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks.  A 6th grader would study this and say, “you’re building software and having fun?”

What Happens in the End, IF the Waterfall Project is Successful

There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful.  The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately.  This cleans up things and improves morale, all while getting the project back on track.  The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management.  Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.

In Summary

These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used.  I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government).  Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another.  This is something else I’ve seen far too often.  This is a complete misrepresentation of what Agile Ideals and processes are.

The Questions

I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations?  Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed?  Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?

Please leave a comment or three.  🙂

Software Project Baseline

There are multiple phases to a software project.  In this blog entry I would like to talk about and discuss (please leave a comment or two) what the basic things are that a software project needs to get started and prospectively move through development and on to a successful deployment.  The following is a short list of the key items that a small software project needs to move forward.

Core Ideas and Staff

  • The core idea must be available via a readily available resource.  This could be an individual such as an analyst, a customer, or other person.  Another option would be some written definition, detailing the high level concepts of what the application could do with avenues for determining more specific functionality as the project moves forward.
  • The appropriate leadership;  project manager, application architect, application designer, or other leads need to be available and have an understanding of how the project will be accomplished from a staffing level.
  • Appropriate staffing for engineers, user design experience, and others that will do the technical work.  These individuals would preferably know what the above stated core ideas are, be in continuous contact with the key stakeholder who lays out the core ideas, and be knowledgeable in the realm of the technology that will be used to build and deploy the software.
  • Project ideology and methodology needs to be clearly defined and explained to all members of the development team, user experience, customers, and anyone involved in the project.  This needs to be done shortly after the core idea is laid out.  This aspect of the project is basically the “strategy” or “game plan” that will dictate how the day to day operations of the project are performed.  Lean Agile with a proactive vs. reactive nature, SCRUM with a high level waterfall at the executive level, and others are examples of ideology and methodology.

Technical Bits

  • A development technology stack, or at least some of the main pieces (IDE, main programming language like Java or C#) needs to be identified to focus around.  This needs to be done early enough to determine appropriate staffing skill sets, but not too early as to derail the focus on the core ideas.
  • Appropriate machines, with at least basic operational software (It could be Linux with OpenOffice, Windows 7 with Office 2010, or simply an Internet enabled device running Google SaaS Office Apps).  These devices need to be made available before the start of the project for every staff member.

Summary and Questions

These are the basic things that I could think of at a very low level.  I am trying to create this list at a very simple and basic level.  In a future entry I will extend past this to what is needed from a practices point of view in more detail, and the same for the technical bits.  I would love to get any feedback on additional items for these lists.  Please leave a comment or three and help me out if you would.