I was asked about Agile the other day and it got me thinking again about how to get started with Agile. This what I suggested;
Here are some starting points for Agile.http://agilemanifesto.org/
http://blog.rawsthorne.org/?p=59
http://www.extremeprogramming.org/index.htmlI’ve read a number of books on the subject and the standout for me is; “User Stories Applied for Agile Software Development” by Mike Cohn; http://books.google.ca/books?id=46ZQAAAAMAAJ&pgis=1
When you start getting deeper into Agile it would be strongly suggested that you get involved with Agile Alliance and find your local chapter. If your in Vancouver we have a strong group of people involved who spend considerable time looking at Agile from many perspectives.
As time passes my appreciation for the power of Agile increases. Even though I haven’t run an Agile project for over two years, I still manifest its principles in my current enterprise architect position. In particular, what is held within the agile manifesto. I apply this by always seeking to interact with the business users where I seek to find out what is actually working within the enterprise software “ecosystem” and what the environment could handle as technology change. It is the collaboration with the business users that makes responding to change so much “easier”. For when everyone is engaged and understands the why without the surprises of top down decision making things just go more smoothly. This article begins with the following statement and sums it all quite nicely.
According to EDS, an agile enterprise reacts quickly and transforms based on changing customer demands and market dynamics.
As a technical architect I sometimes find myself thinking about documentation. And what is The purpose of architectural documentation? I see two primary purposes for this documentation; 1) is for training purposes, so people know what is and what should be, and 2) to support sales and marketing when the potential customer asks those sticky questions about scalability and security. I call these 2nd set of documents, “marchitecture”. In an XP / Agile world we try to reduce the amount of documentation, cause it usually never gets read anyhow. As a solution I now suggest the following; for 2) video record a discussion with the architects as they describe the architecture on a white board. Store this video on disk somewhere shared. For 1) Any architectural components which are client focused should be archived into written documents. The two primary candidates for this “marchitecture” documentation are; scalability architecture and security architecture. These two are the most commonly requested architecture documents to build customer confidence during the sales and marketing efforts.
Today we were discussing staff build up for a company I am involved with. Hiring staff is an interesting and very complex process when you think about it. Finding the right person to fill a job is very hard. Particulalry when you are building upon a staff of a 24 person start-up. Getting the right people, in the right job, at the right time, can have a huge impact on success. All this said, one of the other leads asked me what I wanted to do. It was an easy question to answer; “Process and architecture, I want to ensure we have a good process in place so I can start influencing architecture. Without process how can I ensure that the architecture I drop in at the begining of the development process, pops out at the end. You need process to implement architecture.” Quite a brash thing to say, and true. It would seem that the Carnagie Mellon Software Engineering Institute would agree with me.
I was busy studying for one of my Masters courses and I’m having to describe a teaching scenario that I have utilized in the last few years and identify if it would be considered behaviorist, cognitivist or constructivist. All very interesting and it got me thinking about a course I taught about software development methodologies. This was a two term course where we covered Rational Unified Process, Microsoft Solutions Framework and Capability Maturity Model. And yes, a great course in my mind. I was reviewing the learning outcomes of the course and reflected upon them. I came to the conclusion that two of the most important factors in methodology for software development are; strongly defined roles and responsibilities and bidirectional traceability. The roles and responsibilities keep people motivated cause there is no question to what they have to do and the traceability forces quality. The course I taught would be considered constructivist. It build on ideas taught in the first course and forced the students to participate together in problem solving activities.
I think I may have stumbled across a source of information for my software quality and start-up success relationship query. If you have been reading my blog you will know by now that one of my threads of activity is looking for quantitative evidence that software quality and good software engineering practices have a positive influence on a software start-ups success and ROI. Well, I’ve become frustrated with the challenges I have encountered in not finding quantitative evidence. So, I started thinking I should initiate a formal research project, and given my past positive experiences with IRAP and the NRC I could approach the NRC about my query as a research project. So during my searching of the NRC web site I found that they already have such a project underway. I’ve initiated contact, I’ll keep you updated as I discover more information.
So I’m still searching for evidence on the positive relationship between software quality and technology start-up success. And I found some more, It was anecdotal evidence, but it was very strong evidence to say the least. Today, I was priviliged to speak with a fellow who had had a couple of start-up successes in the wireless world. He described to me how he’d worked with some very experienced software engineers. They were rigorous in their engineering discipline, everything was documented, architecture though to code modules. Nothing was built without proper design and test harnesses. Often the test harnesses were more extensive than the actual module. All this rigor paid off. When ever investors or potential partners did their code level due diligence, they were in awe. Essentially the code quality was better than the already established potential investor or partner. Each module was so solid, their code base became like using lego. If they needed to shift the company direction, they were able to inherit 80% or more of the code base. If they had a potential customer they could redeploy within hours to meet the need. The person I met with said it’s all about execution. To be successful in a start-up you have to be nimble, and you have to execute, execute execute. Having rock solid, modular software allows this.