May 17th, 2012 | Agile, Concepts, Lean Startup, Practices, Process
“Devoted to Facebook IPO”
Is there any development process that can really increase chances of the software system market success in this uncertain world?
Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.
Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.
User Story captures the ‘who’, ‘what’ and ‘why’ of a requirement in a short simple way from the customer perspective. A user story is a unit of requirement, estimation and planning. It should be testable and fit into a single iteration. Often a user story is broken into programming tasks which describe specific implementation steps.
User Story is done when it is:
- Code Complete and Working
- Accepted by customer
Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.
The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.
However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.
Read full post >>
Feb 10th, 2012 | Architecture, Concepts, Design, Practices, System
The software system in the period of active growth is a really wild beast. Excited developers with creative minds and feature obsessed marketers consistently add the fuel to this fire of software creation.
Uncontrollable growth, race for features and engineering wonders sometimes give rise to a monster – a software system bloated with useless features, over-engineered internals and erratic behavior.
Read full post >>
Jul 10th, 2011 | Practices, Process, Productivity
What does a customer wants?
Usually your customer wants to know a simple thing – when your team will deliver working software based on agreed requirements. They naively want to safely bet on highly uncertain future outcome – delivery of the complex never created before system that completely fulfil their dreams.
The customer wants reliable McDonalds experience, but with a little tweak – they want to hand in their own exclusive menu, often created by people who don’t have any idea how to cook.
In short, the customer requires creative flexibility of Cooking Master Chef fortified by ability to predictably deliver hamburgers as McDonalds.
But, is it possible in our development reality to chase two opposing goals – Predictability and Flexibility in the same time?
Read full post >>
Apr 24th, 2011 | Practices, Productivity, Skills
Sometimes I am stuck on a mind-boggling task. I know this because I found myself fiddling around, giving advises to other people, searching for food, drinking coffee or working on low priority stuff. Clock is ticking but little gets done. After I notice this unfortunate state, I talk with myself seriously – calling to conscience, sense of duty and pride of a man who never fails his mission and the team.
Over the time I have learnt how to return to a productive state and even finish difficult tasks. I want to share my experience here.
I assume that you have a good idea what you should build. If not, you have to get back to your notes, client or a drawing board. You definitely will be unproductive if you don’t have clear understanding of your task. Most probably you will waste your time and client’s money.
Now, you know what to do but don’t know how and intellectually overwhelmed by this too big to bite piece!
I recommend 3 phase strategy to conquer your difficult task:
- Hit the road – start moving and build the confidence
- Take control – conquer uncertainty and map the road
- Accelerate – drive on full speed while keeping control Read full post >>
Sep 13th, 2010 | Concepts, Management, Practices, Productivity
Seasoned project managers will tell that delivery of software is result of many trade offs. The main trade off is between Time (when project will finish) and Scope (how much will be done). This post will show that using right tools you could gain improvement for both variables.
While it is possible to create orderly step-by-step process for increasing productivity of software teams, it will never be ideal – too many variations and situations will hinder it usefulness. I believe in set of useful tool that could be combined to craft custom optimal solution.
There are several strategies that lead to increase in productivity – how many units of scope software team can produce within fixed time.
- Increase Capacity (Capacity) - increase capacity by hiring more people or increasing work hours
- productivity is increased as result of more resources and hours available
- Improve Value Stream (Value) - increase added business value on each step and reduce waste and overhead
- productivity is increased as result of optimized delivery of value
- Adaptat to Reality (Adaptation)- learn from practice and mistakes, validation of ideas by reality, adapt to changing situation
- productivity increased as result of early corrections and improving how things are done
- Empower Individuals (Individuals) - boost people knowledge, skills, morale and focus
- productivity is increased as result of higher individual performance and motivation
- Enhance Communication (Communication) - improve communication and mutual understanding inside and outside of the team
- productivity is increased as result of availability of necessary information, clarity of what should be done and exchange of ideas for implementation
- Organize Better (Organization) – structure team and assign roles for better coordination and decision making
- productivity is increased as result of better decisions and focus on important areas
- Expand Expertise (Expertise) - increase range of skills and services offered by team
- productivity is increased as result of better execution of necessary project activities
- Scale Externally (Externality) – outsourcing and involvement of external communities
- productivity is increased as result of involvement of more people outside of team
- Tame Complexity (Design) – manage complexity and provide simple and well designed solutions
- productivity is increased as result of reducing complexity burden on software development
- Preserve Quality (Quality) – use defensive tactics to ensure high quality
- productivity is increased as result of preventing system flaws and reduced effort to fix bugs
I separated tools into three categories:
- People-oriented – people are the creators of software and have major effect on output
- Process-oriented – the way how people work has significant impact on outcome
- Development-oriented – development practices and approach to the system implementation matters a lot
Read full post >>
Apr 25th, 2010 | Expertise, Practices, Skills
“Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen” – John Steinbeck
Your success in life mostly depends on two things – luck and ability to solve problems. I would leave luck
topic for Irish tales and concentrate on the topic of creative problem solving.
Any active person constantly facing many problems and challenges. For example,
- Improving relationship
- Flying to space to be the first man on Mars
- Overweighting and health problems
- Winning bodybuilding or beauty contest.
- Learning new technology
- Making more money
- Building next Facebook or Twitter
- Raising kids
- Boosting career growth
- Becoming Olympic champion or billionaire
- Making the world a better place
- Planning a dream vacation
- Seeking for happiness…
We often are inconsistent in solving problems and cannot find a good solution. This post focus on effective and creative problem solving by offering systematic approach and wide range of techniques.
Read full post >>
Dec 24th, 2009 | Concepts, Practices, Process
Jason Cohen posted an interesting and provocative argument against Release Early, Release Often principle followed by many agile teams.
His main points:
- Ideas. The best ideas are not coming from users and they are bad in providing feedback (iPod). So, there is no point to release early to get their opinion and ideas.
- Features. Minimal early set of features could be unattractive for majority of users and will turn them down for future use (Apple Newton)
- Quality. A buggy and unpolished product could ruin your reputations
- Architecture. An incorrect initial architecture creates waste and serious problems down the road (Netscape, Twitter)
Therefore, Jason against releasing early and often. I don’t agree.
My answer: it depends!
Evolution is the process of small frequent changes to improve and adapt to environment.
Read full post >>
Nov 16th, 2009 | Concepts, Practices, Process, Productivity, Teams
The manager slams a door and tells us that we are in a big trouble. Our old customers complain about many bugs and bad performance, new customers complain about delays and lack of dedication. And, top management considers our department financially unsustainable and wants to deeply cut expenses.
The manager tells that we are brilliant programmers, work very hard and create cool software solutions. But there is something wrong and we cannot work this way anymore.
Anxiety started to penetrate our souls. We know what is wrong: our team is short of people, we have too many commitments, our code is becoming a big mess, new technology and our new software version makes something bad with servers. A snowball of different problems makes us stressed, distracted and incapable of productive work.
What could our manager do next?
- Distrust. Become a dictator, make own decisions including hiring external consultants to recommend what to do or even replace us. However,
- we are good programmers and know our business well – the problem is not in lack of skill and knowledge
- external people will take a lot of time to understand the system and they will have different motivation and won’t care about the long-term success
- people will be demotivated and the manager cannot make effective decisions without active team involvement
- Faith. Give to team the full power to fix a problems and make own decisions in hope that smart people, motivation and technical expertise will do magic. However,
- fresh outlook and thinking out of box are hard when a team immersed for a long time into difficult situation
- a team possibly doesn’t have understanding and control over external forces – management, customers, finances
- changing of reality is tough (especially in people heads) and requires more than technical experience
There is a third way. Place improvement practices in the core of development process. Make self-improvement inevitable and required for any activity. Do it every day.
Toyota Way is the best example of large-scale reliable self-improvement process. It focuses on eliminating waste, solving problems at root cause and making right decisions. Toyota Way reduces problems, increases internal efficiency and makes a company successful. This is the best receipt for coming out of crisis.
- Problems - emergencies, fires that require immediate fix: bugs, server crushes, deadline slips
- Waste - inefficient and non-value adding activities: waiting, misinformation, stress
- Challenges - adaptation to external forces (market, competitors, customers, society): new trends and technologies, changes in users expectations for user interface and functionality
Read full post >>
May 11th, 2009 | Concepts, Expertise, People, Practices, Skills
Reality is merely an illusion, albeit a very persistent one – Albert Einstein
An expert have much better models of reality and methods to build them than an ordinary specialist. The expert, armed with these models, can quickly put pieces of a problem puzzle together, find explanations and solve the problem.
Models can be related to anything – software systems, business domain or your personal relationships. Read full post >>
Mar 15th, 2009 | Expertise, Job, Practices, Productivity, Skills
experts are made, not born – Scientific American
Disclaimer: This post is devoted to a person who wants to become an expert – the top player in a specific field as programming, soccer or chess. This post will be not interesting for people who are satisfied with their current performance and not interested to be the best.
If you want to become an expert, it is not enough to follow your work assignments or occasionally play with interesting stuff at home. You have to push yourself hard in specially designed way.
Your paid work tasks and projects are not designed to make you an expert. Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal – make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods. We cannot blame our organizations – this is part of the deal – they pay for your work and expect specific results. But… is this the best way for you to become an expert, acquire new skills and gain knowledge? To become an expert, you have to make many mistakes, learn from them, experiment with alternatives and work hard on your weaknesses. How many organizations do allow this risky, unproductive and unreliable way of working?
Your play at home with interesting stuff has problems too. To satisfy your programming instincts and curiosity, you will probably select what you enjoy to do and eager to try. You’ll immense in this activity and find great satisfaction from doing it. But… is this the best way to become an expert by doing only what you like? Becoming an expert requires hard, sometimes unpleasant work, specifically designed to improve your performance and push you over comfort zone. Read full post >>