En gang i året sender Iterate 3 av sine senior konsulenter til Oregon. Og hvorfor det? Oregon er hjemstaten til Kent Beck som mange kjenner som mannen bak extreme programming og jUnit. Kent er Iterates Chief Scientist og en person som man kan lære utrolig mye av. Og det er akkurat derfor vi er på vei ut til Oregons villmark for å dra på Code camp hjemme hos Kent. Vi er Ivar, Mari og Rana som alle tre er utviklere og har jobbet i Iterate ganske lenge. Vi reiser til Kent med forventninger om at vi skal lære mye om programmering og hvordan man i praksis jobber med Lean startup.
Vi kunne selvfølgelig valgt å jobbe med helt vår egen businessidé. Men i forkant av reisen vår hadde vi vært i kontakt med Elixia og hørt om de kunne tenke seg av vi jobbet videre med en del av nettsiden deres som har med verving av medlemmer å gjøre. Vi kjente til denne fra før da denne var blitt utviklet av et av våre dyktige sommerjobbteam sist sommer. Det spennende med dette var at dette var at sommerjobbprosjektet ble drevet som et lean startup prosjekt og har vært i bruk fra elixia.no sidene i ca en måned. Det gir oss en unik mulighet til å ta utgangspunkt i data generert utifra bruken til vervesiden og se på hvordan vi kan gjøre verveprosessen til Elixia enda mer effektiv.
After writing about introvert and extrovert organizations, I’ve been challenged to come up with more examples:
Imagine an organization that is more than 100 years old. It has a demanding and highly conscious customer base, who expect nothing but the best. Which is what they get, with live deliveries on a consistently superior quality level, multiple times a month, with constant alternation of leadership.
For 130 years.
This sounds more like an extremely steady delivery organization than an innovative one. In fact, any organization who’s even remotely resembling such seemingly impossible behavior is likely to resist anything new. Never change a winning team, as they say.
@hauge2: What are the characteristics of organizations that help its people innovate? Vice versa: What do they look like, organizations that unintentionally obstruct creative work?
Innovation can be categorized from continuous (improving existing products, e.g. the Hybrid car) to disruptive (changing an entire market, e.g. the digital camera). In order to understand serial innovation – companies that succeed with innovation over and over again – I however believe we need an additional organizational dimension:
So what could be the labels of my organizational dimension? New vs. established? Top-down vs. bottom-up? Independent vs. embedded?
At a recent beerstorming (*), we discussed how to make nearshoring of software development work. Funny enough, the smooth taste of Yogurt entered the picture.
(*) Beerstorm is a fun-name invention for a practice came out of experimentations; it has very good effects on my spirit, it literally drags me into the zone…
A primer on Yogurt cultures!
Yogurt brewing, when done the natural way, is a fascinating process. A perfect example of nurturing a self-reproducing organism. The bacteria used to make yogurt is known as “yogurt cultures”. Fermentation of lactose by these bacteria produces lactic acid, which acts on milk protein to give yogurt the characteristic texture we love.
As a consultancy, we’re always on watch to see what might be the next step forward in the field of software development. I usually find that paying attention to what our developers are playing with provides a good clue.
These days, many of them are toying with Scala, and they are eager to try it out on a project. I have challenged them to come up with compelling business reasons to use Scala on a project, but they have come up short.
I figured I would help them find a good business case for Scala.
For software companies in a tight employment market like the one in Norway, most technical advantages are dwarfed by one concern: Access to good developers. It clearly doesn’t matter what kinds of technical advantages a new language can bring if you can’t hire any developers to work with it. On the flip side, if you can bring great developers to your project, you’re probably in good shape no matter what language you have chosen.
The question, then, is what language should you choose to maximize your access to good programmers?
We’ve outlined 7 questions to innovators in established organizations. Each question has two possible answers, but you may only choose one of them.
The good news is: If you choose the latter, you may eventually also achieve the former.
1. Success defined as Growth or Innovation?
Growth is about optimizing revenue and economy of scale. Innovation is about learning what works and what doesn’t. You can’t grow a product before you know the effect it has on customers.
2. To Show off or To Show the way?
Leaders that show off are driven by the expectations of the surrounding organization. This is about handling – and improving – what we already know, and have. Leaders that show they way will show – not tell – their entrepreneurs why they go to work. They make sure that great ideas win over fear of the organization. If necessary, such leaders take chances by making decisions that possibly threaten their career.
3. Solving the problems of Stakeholders or Customers?
Solving the stakeholders’ problems is about making sure you fit in the corporate puzzle. Solving customers’ problems is about learning and adjusting – possibly several times – before finding a product that customers really need.
4. Taking a Position or following a Vision?
Position is about keeping competitors from “stealing” your shares. Vision is about building great technology that solves real problems for real people, possibly making you pioneer a new market.
5. Teams expected to Deliver or Iterate?
Delivering is about launching something that looks complete and impressive, and adds to your existing reputation and brand. Iterating is about learning, in small steps, first under the radar, later in the market majorities. In the beginning of learning, dialog is your weapon (and you can’t Deliver dialog).
6. Organized around Expertise or Autonomous Units?
Expertise is about putting the most experienced people in charge, pick their brains and try to repeat their success. Autonomous units are fast-learning cross-functional squads with just enough people and skills to be able to solve problems outside your organization - without having to ask anyone for permission or help to get the job done. Such units are also expected to fail and learn from it.
7. Developing Heroes or Culture?
Developing heroes is about promoting, and keeping, key personell with skills critical for maintaining your products and services. Culture is about developing knowledge workers into great teams, who in turn can build new great teams (even when the heroes quit).
If you’re either planning for it, or your are in the middle of an innovation effort, we encourage you to discuss these questions with everyone involved. From director to programmer.
We hope it will help you discovering how you should be set up. The war is out there, and in order to win you want to get started without applying any brakes in here.
Our code has been broken for weeks. Compiler errors, failing tests, incorrect behavior plagued our team. Why? Because we have been struck by a Blind Frog Leap. By doing multiple concurrent changes to a key component in the hope of improving it, we have leaped far away from its ugly but stable and working state into the marshes of brokenness. Our best intentions have brought havoc upon us, something expected to be a few man-days work has paralized us for over a month until the changes were finally reverted (for the time being).
Lessons learned: Avoid Frog Leaps. Follow instead Kent Beck’s strategy of Sprinting Centipede – proceed in small, safe steps, that don’t break the code. Deploy it to production often, preferably daily, to force yourself to really small and really safe changes. Do not change multiple unrelated things at the same time. Don’t assume that you know how the code works. Don’t assume that your intended change is a simple one. Test thoroughly (and don’t trust your test suite overly). Let the computer give you feedback and hard facts about your changes – by running tests, by executing the code, by running the code in production.