Recycling or Not!?
Everytime requirements are being defined, ambiguity just goes nicely along with it. I had to check twice to find out what belongs into the bin with this sticker.
Reward and Recognition Program for Agile Teams
totally forgot to mention my article in the agile journal last month about an internal reward and recognition program for agile teams called.
Comment » | General Agile, Practices and Techniques
Incrementor(s) Needed
Immediate need for one (possibly two) Incrementor(s), who would like to work on a contractual basis for 6months+ engagement in the NYC area.
The first step will be to fill the role of a hands-on Scrum Master and help teams new to agile to overcome initial hurdles and demonstrate business value of agile practices.
This opportunity should attract agile all-rounders and practioners who have a hands-on experience.
Local candidates only. No travel required. On-site with team
5-days/week (40h). Please send resume to start initial dialogue. (jobs@incrementor.com)
Not just agile
Organizations perform business analysis for a variety of reasons. For example increasing performance throughput or improving the quality during execution for existing companies. For a new business, a business plan is most likely presented to the stakeholders and its owners. That contains but is not limited to a mission, strategy, goals and competetive landscape of the future endeavor. This are extremely important activities and although we embrace change through agile practices, a vision should be a fairly stable and thought through deliverable.
I came across a store “Not Just Bagels”, where I felt that the opposite was the case. I am sure the store owner had good intensions the name of the store has two issues.
First, I thought the shoppe was specialized on bagels, but because the name of the store degrades bagels by using the word “just”. Then I thought if the store is not specialized on bagels, but the name of the store does tell me that. The takeaway of the story is that a little due diligence in business analysis pays back in the long run.
Vision vs. Reality
This is funny example of how a vision was implemented. Reality seems to be far away from anything royal.
User Experience Design
Parking couldn’t be easier with a payment device like this!
What should have been a relatively straight forward human-machine interaction (stub in, payment in, pass out) turned into something much more on the front end. Although the pay station’s business rules work correctly, the user-experience team must have been disconnected from the actual delivery team.
I put a dollar in a change machine. Nothing changed (George Carlin)
Happy New Year everyone!
We are approaching a new decade and I asked myself if this will be (finally) the decade for true agile software engineering?
I recently came across this wonderful line by George Carlin. It captures the essence. Change is not easy and takes time. Change is about existing knowledge, behavior, routines and work habits many of us have become used to. It is hard to break out of them. Changing the way we are building software is not like switching from one programming language to another. There is a much more complex component to it. The team.
A team on the other hand is just a group of people which performs as a whole. But it is not only about changing team member indivually, we will need to change the way the team works a group as well. Collaboration, communication, values, skills, goals, dreams, visions and aspirations. All that has to be synched up to achieve a groovy team.
When iterative-incremental development became mainstream in the mid 1990s, I was very hopeful that the the first decade of this century would be dominated by pure agility. Considering the manifesto was written and released early 2001 already. What has happened the nine years after? The agile community has an ever increasing group of supporters, but we are still being looked at in many ways as the rebels who do things very different and unconventional. To be honest, back in 2001, I did not expect to be still at this level as an industry by the end of 2009. I do my part to make this work, but let’s put another dollar into the change machine in the meantime and hope for the best. cheers.
Initial Scrum Team Training Rating
After two 2-day Scrum Team trainings (2x 20 students) , the initial verdict is in! On a scale of 1-9 (1 the lowest, 5=ok and 9 the highest), participants rated the Incrementor Scrum Team training as 8.62 in average. Going forward I will share and update the training ratings publicly on this website. The initial feedback is simply awesome and I am very proud of the responses. It also shows that quality in the improvement process will lead to an overall better customer experience.
Remember the Scrum Team training is not your ordinary Scrum Master certification training. Beside Scrum roles and reponsibilities, product backlog management (requirements with user stories), sprint planning and execution, it covers also the hardest parts for future Scrum teams; communication and collaboration.
Beginning of January and February, two more Scrum team trainings are already scheduled in the New York City area. If you are interested in bringing this (or other) courses to your organization, please reach out to me directly.
Comment » | Incrementor, Seminars and Workshops, training
Brand New Scrum Course - Scrum Team Software Development
I am currently working on a brand-new Scrum course which I will be offering exclusively to agile teams on-site (no open enrollment) next year. The course will target entire development teams with a focus on building high-quality increments from a software engineering perspective. If we are hitting the keyboard in this course is still undecided, but we are definitely getting as close to it as possible.
The purpose of such a course is the need for building software in a way that future increments of an agile project integrate with work from previous iterations. That sounds like a humble effort, but is in reality a typical problem when changes in the product backlog result into curve balls for engineering teams. If you are interested in learning more about this course, please reach out to me directly.
Comment » | Seminars and Workshops
Extreme User Personas
Interaction design becomes more and more important for agile teams catering to organizations which present themselves, products and services in the internet.
Prior to the internet, the audience of a system was relatively easy to size and define. More important you could just talk to them and gather and clarify requirements. When systems are opened up and made available around the world, new challenges emerged instantly. For example languages, currencies or units of measurements typicially refered to as localization.
Although these issues can be tackled country by country, there is still some uncertainty. For example, who actually sits in front of the computer? Interactive designer in agile projects often use user profiles and user personas to describe and classify these users. That process is part of user modeling. These profiles are then connected with user stories which are inside the product backlogs. Although we can collect data about servers, timing and number of visits and requests, we just don’t know who the actual living person that punches the domain name into a internet browser and the their motivations for activating certain content pages.
What I realized in past discussions with clients who wrote user stories and created intial product backlogs is that the teams tried to create a ”typical” user profile for their audience.
“Helen, female, 32 years, living in suburb, $90,000 income a year …”
This persona for example could represent that fictional “average” user. The problem with average is that it is usually sub-optimal, imprecise and actually not that representative as we think. Because Helen was created for the sole purpose of giving the average audience a face. One big assumption (and often mistake) is that project teams over time forget about the rest of the audiences and tunnel in on “Helen”.
Good industrial designers (objects) however take a very different and more extreme approach. Instead of wasting time averaging and generalizing users, they are searching for two personas only; these are the two most extreme on both sides of the range of potential users. Industrial designers cater to the extremes because they know that the middle (average) will automaticially fall into place even if that is the target audience. That approach was used to design the generations of iPods and these products have been proven successful for young and old because they were so easy to handle. Obviously the middle aged user group liked “easy to handle” as well.
Imagine we would build two different online food magazines one catering to the gernalized and the other one to the one using extreme ranges. Although the first might be the correct average, it excludes the majority (if not all) of the actual users. The latter technique might cater much more precise to a very small group, but is so defined that the vast majority of users will find themselves in the set range.
Comment » | Practices and Techniques