Skip to content

Blogs

Gute Entwickler sind schwer zu finden!

Scrum 4 You - Wed, 07/09/2014 - 07:52

In einem Training, an dem ich letztens teilnahm, kam unter den Entwickler wieder ein Mal die Diskussion auf, dass es doch gar keine guten Entwickler gäbe und es so schwer sei, neue Mitarbeiter zu finden. Die Teilnehmer, eine Handvoll jahrelang in der Softwareentwicklung erfahrener Menschen, waren alle der Meinung, sie kriegen keine guten Leute, die Entwickler von heute wären alle nicht brauchbar.

Nach regem Kopfnicken und Zustimmung fragte doch tatsächlich einer der Anwesenden, was denn wohl die Gründe dafür seien. Diese Frage warf natürlich wiederum eine andere auf, nämlich: „Wer ist denn ein guter Entwickler bzw. welche Kriterien erfüllt dieser?“ Da es ein Training zum Thema Selbstorganisation war, haben wir uns einfach einige der Anforderungen an die jungen Bewerber genauer angesehen.

  • Zunächst möge der Junior Entwickler genug Erfahrung mitbringen. Wie soll denn der Junior Entwickler Erfahrung sammeln, wenn alle nach Junior Entwicklern mit Erfahrung suchen? Nun gut, nach diesem Einwurf erbarmte sich einer der Teilnehmer und meinte : “Ja, man kann den sicher auch einarbeiten, ist ja noch kein Meister vom Himmel gefallen“. Puhh Glück gehabt, unser Bewerber hat unsere 1. Anforderung mit Ach und Krach geschafft.
  • Der Entwickler sollte mit mehreren Tools umgehen können (es wurden so viele aufgezählt, dass der Platz auf dieser Seite dafür nicht ausreichen würde). Okay, einer kann ja nicht alles wissen, da waren wir uns alle einig. Aber zumindest die gängigsten Tools sollte der Entwickler im Schlaf beherrschen. Damit war auch der Großteil einverstanden. Vor allem sollte sich der Bewerber nur bewerben, wenn er tatsächlich die im Inserat angegebenen Tools auch beherrscht. Auch bei diesem Einwand wurde rege mit den Köpfen genickt.
  • Der Entwickler möge sich seine benötigten Informationen selbst erarbeiten. In diesem Punkt gingen wieder die Meinungen auseinander. Die einen bestärkten mit Kopfnicken, während die anderen meinten, eine gute Einarbeitung seitens eines Seniors wäre unumgänglich. Bei diesem Punkt wurde sehr schnell das Thema Wissenstransfer angesprochen und auch die Tatsache, dass Senior Entwickler ungern ihr Wissen teilen. Aber auch bei diesem Punkt waren wir uns größtenteils einig. Ein neuer Junior Entwickler könnte genau diesem Problem entgegenwirken. Wir würden einen Senior Entwickler aus dem Team zu den Bewerbungsgesprächen dazuholen, damit er auch mitbestimmen könnte, wer eingestellt wird. Da auch er derjenige ist, der den neuen Mitarbeiter einarbeiten wird.
  • Die Arbeit mit agilen Methoden wie Scrum, Kanban oder ähnlichem sollte für den Junior Entwickler selbstverständlich sein. Hier waren wir uns natürlich alle einig. Ein kompetenter Mitarbeiter, der selbstverantwortlich und selbstorganisiert arbeiten kann. Der cross-funktional arbeitet und über ein agiles Mindset verfügt. Oh ja, unser Herz ging auf bei diesem Punkt, und wir nannten noch viele weitere Punkte. Doch dann sagte einer: „Aber genau das ist der Grund, warum wir keine guten Entwickler finden.“

Was sollte das heißen? Wir waren alle doch recht verwirrt nach diesem Einwand.

Seine Theorie:
In einem agilen Umfeld sind Soft Skills gefragt. Wir erwarten uns von den Entwicklern, dass sie kommunizieren, sich mitteilen, diskutieren und Entscheidungen treffen. Doch viele Entwickler werden Entwickler, weil sie sich nicht austauschen möchten und sonst kein Interesse an Kommunikation haben. Hinzu kommt, dass sie gerne Vorgaben haben, nämlich genaue Vorgaben. Diese Vorgaben nehmen sie, gehen in ihre Kammer und coden, bis sie alles abgearbeitet haben. Doch in einem agilen Umfeld planen wir iterativ, wir lernen dazu und verbessern uns immer wieder. Diese Entwickler tun sich sehr schwer mit dieser Art des Arbeitens.

Er glaubte tatsächlich, dass die fehlenden Soft Skills, die im agilen Umfeld erwartet werden, bei vielen Entwicklern nicht vorhanden wären, und dass dies der Grund dafür wäre, warum sich so schwer gute Entwickler finden ließen.

Und auf diese Ausführung hin gab es erneut reges Kopfnicken.

Related posts:

  1. Systemische Fehler in kleinen Firmen
  2. DeutscheScrum
  3. Ken Konfuzius Schwaber: Der Weg ist das Ziel

Categories: Blogs

Living The Dream. Or Is It A Nightmare?

Derick Bailey - new ThoughtStream - Wed, 07/09/2014 - 05:29

Have you ever heard of Etsy? Or Ebay? Maybe you’ve heard of Twitter or Gawker? How about Crashlytics or Airbrake, or Raygun? Of course you have. These are well known names on the internet and in techie circles. I mean, who hasn’t heard of Twitter and Ebay, even outside of the techie circles? Maybe people who don’t use the internet.

But do you know what they all have in common? They all use MarionetteJS (or have used at one point) – the Backbone application framework that I created during my consulting days, a few years ago - somewhere in their projects, products and services.

And you know what? The success of MarionetteJS terrifies me.

Scared of success

The Best Thing I Ever Did

Around a year ago, I turned over the keys to the MarionetteJS castle. I was working for Telerik at the time, loving my job but unable to put in any real time and attention in Marionette. So along comes this random (to me) guy named Sam Saccone. He’s been using Marionette for a while and he wants to help in any ways he can. It starts out with grooming the issues list. It quickly turns in to him fixing bugs. Next up, he’s putting together releases. And before I know it, I’m handing him the keys to the castle. And you know what?

The best thing I ever did for MarionetteJS (other than creating it) was turning it over to someone else.

I have no doubt in my mind that the continued growth and success of Marionette is due to the team that Sam assembled around it. It’s an amazing team and they are doing amazing things. I was actively holding back the project with my inability to get issues resolved, move it forward with significant new functionality, clean up the ugly parts of the API, etc. I may have been good for Marionette when I created it and curated it in to v1.0 land… but it’s obvious to me, now, that I was the one holding it back. 

Living The Dream

Most software developers that contribute to open source projects have the dream of one day working on or building the next big thing. It’s human nature to want that kind of recognition and power and awesomeness. I got lucky with Marionette. I was in the right place at the right time, had the right set of skills and the right circumstances in which I could execute on my ideas. It worked out well for me and for the Backbone community at large. 

For a period of time, I was living the open source dream. I was the man in charge of something epic. I had the vision, the philosophy, the idea… I somehow created an open source community that actively sought to help others, in spite of me. I led the charge and set things in motion. I got to live the dream.

And then I left.

Is It A Nightmare? Cause I’m Scared.

When I look at the success of Marionette… when I watch videos of the guys from Etsy talking about what they are building with Marionette… when I see tweets showing screenshots of Gawker using Marionette… I get a little sad. I think to myself “what could have been…” if I had stuck around and not left Marionette when I did. Then I realize that the success of Marionette now is due to my having turned it over and I swell with joy and jealousy at the same time, at what the Marionette team has done. 

And then I run away screaming. Terrified.

The thought of my code… my projects… my baby that I labored over for near 2 years… knowing the mistakes I made, the dumb things I did… seeing my code in the hands of such amazing companies scares me. 

Here’s the thing… I want all the success and fame and D-List Celebrity status that being the founder of a “big” (ok, maybe medium-ish sized) open source project brings with it. But I don’t want the responsibility. I want to be the guy with the name, and I’ve been that guy for a while now. I want to be known as the one that started it all… and I am… but inside, I’m still a scared little boy that has no idea what to do with this.

On Success

People ask me to help them with projects every week. Every. Week. Sometimes every day. I’m glad I don’t have time. I’m sad I don’t have time. I’m flattered by the shear number of people that are using Marionette, and the amazing opportunities that this project has brought to me.

And I’m terrified of everyone on the internet seeing that I really don’t have any idea what I’m doing – no more than you, or the next person. 

Impostor syndrome? probably. Isn’t that the latest fad, anyways? I need to jump on a bandwagon now and then. Self deprecating? Definitely. “You are your own worst critic”, right? Well I’m a hell of a critic.

The Fear…

Have you ever wanted to punch someone and didn’t because you were afraid of hurting them? Have you ever punched someone anyways and realized how powerless you are, as they laugh at your attempt to hurt them? I think success is similar to that.

Most of us are afraid of failing. But I would bet that more of us are afraid of succeeding, than would admit to it. I know it terrifies me, sometimes. 

      
Categories: Blogs

Pragmatic Manager Posted: Standup or Handoff

Johanna Rothman - Tue, 07/08/2014 - 15:27

I published a Pragmatic Manager yesterday to my subscribers. Normally, I let them enjoy the pleasure of being “in-the-know” about what I have to say this month for a while before I post the emails to my site.

Read the Pragmatic Manager here: Standup or Handoff.

However, I made a Big Mistake in where I will be speaking this week. I fat-fingered July 10 into July 19. What made it into the newsletter was July 19. Oops. I’m actually a panelist this Thursday, July 10, at Agile New England. The topic: Agile: Massive Success or Empty Buzzword?

My fellow panelists are Ken Schwaber and Linda Cook. We will have no shortage of opinions!

For example, I suspect that Ken and I might disagree on this very issue, of whether you can do agile with a geographically distributed team, and if you can have handoffs or you must do standups.

If you are near the Boston area, this Thursday, July 10, and want to see some sparks fly—or at least engage in lively debate—come to the Agile New England meeting July 10.

If you’re wondering how did this get past my reviewers, my copyeditor, and me? Well, we all make mistakes, don’t we?

Categories: Blogs

XM Principle 8: Continuously Deployed Development

Scrum Breakfast - Tue, 07/08/2014 - 08:00
Extreme Manufacturing requires going from an idea to a deliverable, working product or service in 7 days or less. How do you produce a new design in volume in such a compressed timeline?

Let's look at how traditional companies address the problem of new product creation: When a traditional car manufacturer designs a new transmission, they build a new factory.  Step one is to negotiate with various political districts for optimal conditions, e.g. access to roads & power, conditions for taxation, etc. Then they acquire the land, build the facility, hire and train the workforce, and configure the line. After many years of preparation, their customers can finally order a product for delivery.

How do you compress years of lead time down to a one week delivery cycle?

This Principle involves making the mass-manufacturing line flexible, so it can produce different products within a 7 day sprint. These products might be existing products, modified products or completely new products.

Achieving this operational flexibility might mean additive or subtractive rapid prototyping machines, or both. It might mean some machines or lean cells are placed on lockable casters so they can be wheeled in or out of the flow depending on the sprint goal. This often means that the team reconfigures the machinery following daily Scrum each morning. And this always means test fixtures connected to andon lights at all stages of the line.

R&D belongs at the head of the line. If the new product design team is within earshot of the volume manufacturing line, bi-directional communication occurs. If the R&D group deploys to the production line every sprint, both teams can work together to reconfigure the line to test and produce the new product. As cross functional skill grows, any separation between the R&D and manufacturing team dissolves and we simply have the cross-functional product team. Each individual has specializations, welding certifications for example, but through pairing they work on every aspect of the product flow from idea to customer delivery and support.

How are you going to get a truly marketable product, if you only have seven days to create a new product? See XM Principle 5: Iterate the Design. The objective is to create a first version within a week. Then iterate on the design to improve it as needed. Use the intermediate results to get feedback from customers, users and other stakeholders. Early designs will be big and clunky, making use of off-the-shelf components, but as you iterate the design and get feedback on it, you will zero in on your target.

For services, the story is exactly analogous. Ideally the service providers are the advanced marketers and innovators of new services, and within a sprint they interact with customers to improve the service and make the improvements available to the customers.

Next: XM Principle 9: Scaling Patterns

The 10 Principles of Extreme Manufacturing

This article was written by Joe Justice and Peter Stevens.
Categories: Blogs

What is an Estimate?

Software Development Today - Vasco Duarte - Tue, 07/08/2014 - 05:00
If you don’t know what an estimate is, you can’t avoid using them. So here’s my attempt to define what is an estimate.
The "estimates" that I'm concerned about are those that can easily (by omission, incompetence or malice) be turned into commitments. I believe Software Development is better seen as a discovery process (even simple software projects). In this context, commitments remove options and force the teams/companies to follow a plan instead of responding to change.

Here's my definition: "Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made."
The principles behind this definition of an estimateIn this definition I have the following principles in mind:
  • Delay commitment, create options: When we commit to a particular solution up front we forego possible other solutions and, as a consequence we will make the plan harder to change. Each solution comes with explicit and implicit assumptions about what we will tackle in the future, therefore I prefer to commit only to what is needed in order to validate or deliver value to the customer now. This way, I keep my options open regarding the future.
  • Responding to change over following a plan: Following a plan is easy and comforting, especially when plans are detailed and very clear: good plans. That’s why we create plans in the first place! But being easy does not make it right. Sooner or later we are surprised by events we could not predict and are no longer compatible with the plan we created upfront. Estimation up front makes it harder for us to change the plan because as we define the plan in detail, we commit ourselves to following it, mentally and emotionally.
  • Collaboration over contract negotiation: Perhaps one of the most important Agile principles. Even when you spend time and invest time in creating a “perfect” contract there will be situations you cannot foresee. What do you do then? Hopefully by then you’ve established a relationship of trust with the other party. In that case, a simple conversation to review options and chose the best path will be enough. Estimation locks us down and tends to put people on the defensive when things don’t happen as planned. Leaving the estimation open and relying on incremental development with constant focus on validating the value delivered will help both parties come to an agreement when things don’t go as planned. Thereby focusing on collaboration instead of justifying why an estimated release date was missed.
  Here are some examples that fit the definition of Estimates that I outlined above:
  • An estimate of time/duration for work that is several days, weeks or months in the future.
  • An estimate of value that is not part of an experiment (the longer the time-frame the more of a problem it is).
  • A long term estimate of time and/or value that we can only validate after that long term is over.

How do you define Estimates in your work? Are you still doing estimates that fit the definition above? What is making it hard to stop doing such estimates? Share below in the comments what you think of this definition and how you would improve it.

This definition of an estimate was sent to the #NoEstimates mailing list a few weeks ago. If you want to receive exclusive content about #NoEstimates just sign up below. You will receive a regular email on the topic of #NoEstimates as Agile Software Development.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to our mailing list* indicates required Email Address * First Name Last Name

Picture credit: Pascal @ Flickr

Categories: Blogs

Kanban Thinking: The Canvas

AvailAgility - Karl Scotland - Mon, 07/07/2014 - 15:51

Kanban CanvasLast week, at SparkConf, I announced a new website for Kanban Thinking, which is where I will add new material in a more structured way (I’ll continue to blog ideas here in an un-structured way!). The primary new piece is what I’m calling a Kanban Canvas – a sheet designed to be printed on A0 paper and used to collaboratively explore the model when designing a kanban system.

The canvas is built around the heuristics and related questions, with the goal being to co-create a design by exploring and answering the questions. You can see some more on this in the SparkConf slides below. Please visit the new site, download the canvas, and let me know your experiences.

And of course, let me know if you would like me to help facilitate your work!

Categories: Blogs

The Importance of Two Things in Agile

Agilecraft - Petri Heiramo - Mon, 07/07/2014 - 14:40

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

  • the product has been properly tested and there are no known bugs
  • the product has been integrated with its environment
  • code is clean and refactored
  • documentation is up to date

If we don’t have that state, it should be the most important thing the team works on achieving. It is generally much more important than adding any new capability into the product.

Because, if we don’t have that state, we don’t have 80% of what makes Agile really work. The team is really doing glorified waterfall. “Almost Agile”, but still not Agile. We also don’t know where the project really is, since there is an undefined amount of work remaining in the features created so far (which is exactly the key problem with waterfall based project management). Essentially, we fool ourselves.

For achieving this in software context, Extreme Programming is a necessary framework (or something very very much like it). Scrum and Kanban are silent on this, but it has always been an assumption that smart software teams are aware how critical it is and use it appropriately. For those who have not experienced XP for real, it is unfortunately too easy to dismiss the importance (because they just don’t understand how much it really changes the name of the game).

Relentless improvement

The second thing is retrospectives – the continuous process of evaluating the way of working (including achieving & improving the technical quality of the product).

Unfortunately, this is often the first thing teams omit in a hurry or when getting less excited about their work. This is a symptom of “work harder” belief gone wrong. Yes, there are moments when working hard (i.e. focusing on getting stuff done) is very important, but it should never replace “working smarter”. And dropping retrospection is exactly that.

All examples of really masterful people or teams exhibit retrospection. They spend time to understand the system and focus on finding behaviors that enable them to get more done at their normal effort. They look at the world with new eyes that allow them to rephrase their problem, thus opening opportunities to new innovative solutions.

Masterful teams understand the importance of potentially shippable outcomes, and continually retrospect any faults that escape their process. They want to understand how to further “error-proof” their work. Of course, it’s a work that will never completely finish or achieve perfection, given that things tend to change and some surprises always happen.

And it is not just the process they retrospect, they also look at other elements of their value delivery. How can we better understand our users real problems? Are we able to come up with innovative solutions? Are we creating a successful business? Do we have the right skills or enough variety in our team? Do we appreciate and support each other enough? Are we communicating effectively in our meetings and daily operation? Are we seeing the reality, or an illusion of some kind? Are our challenges big enough to maintain the drive we have?

And everything else follows

If we follow these two elements, we can distill all other practices and frameworks we need.

We probably need to plan what we seek to achieve in some way (e.g. Sprint Planning and release planning). And we also want to replan daily for surprises (e.g. Daily Scrum) and inspect that outcome with stakeholders (e.g. Sprint Review). And so on. We don’t have to choose Scrum as our framework – we can also choose some other metaphor, like Kanban – but the process does emerge from these needs.

We can also refine our general approach. Is an iterative and incremental approach right for all the things we do? Do we need to assign singular responsibility for certain parts (like prioritizing things to do)?

As a consequence, a masterful Agile team will have a great process, but that process may be unlike anyone elses’ process. And that’s the point – they have not copied their process, but evolved it through countless small improvements and experiments. That’s the heart of Agile.

 


Categories: Blogs

The Next 7 Habits of Highly Effective Coaches: Habit 13 – Motivate with Flow

Portia Tung - Selfish Programming - Mon, 07/07/2014 - 11:00
Habit 13 – Motivate with Flow

One of the greatest sources of satisfaction is achieving flow in what you do. Instead of motivating people through reward and/or recognition, create an environment where people have the chance to practice and get good at what they do. The satisfaction derived from flow will be greater than anything extrinsic has to offer.

Exercise: Free Flow

Identify a goal and a timebox (eg 15 minutes). Then do an activity in that timebox that enables you to get closer to your goal. Notice how you felt as you focused on the task at hand. What did you achieve? How can you flow again? How can you flow on demand?

For more information, see: Ted talk by Mihaly Csikszentmihalyi on Flow, the secret to happiness.

About This Blog Entry

The Next 7 Habits of Highly Effective Coaches is part of a mini series inspired by the style of Paul Coelho‘s “Manual of the Warrior of Light“. You can find the first 7 habits here.

Categories: Blogs

5 principles on quality and testing in the Agile context

Don't get better at scraping burnt toast; get better at not burning the toast in the first place."When you make toast, do you want to burn the toast and scrape it, burn the toast and scrape it  - or do you want to make the toast right before it gets to your inspectors?"  Dr. William Edwards Deming

Inspect-and-fix after the product is built is "scraping burnt toast".  This is inherently ineffective and unscalable. Learning how to not "burn the toast" is about improving how the development process works.
Tests are a way to clearly communicate expectation; establish expectations before, not after development.

Normal language is prone to misunderstanding and false agreement.  Tests, as a more structured medium, more clearly communicate expectations and ensure we get real agreement (or disagreement).


It takes less effort to communicate expectations before starting and meet them than it is to proceed with the wrong expectations and have to correct after having already built the wrong thing.Automated regression testing will lead not to tens, nor even hundreds of tests, but rather thousands of tests.  Therefore automated regression tests need to be deliberately structured for maintenance and performance.

Even minor problems with an automated testing approach or toolset will become untenable as the number of tests escalate.  Typical numbers of tests in an automated regression test suite can run into the thousands, not tens or even hundreds.
The issues that you face with scaling automated regression test suites are pretty much the same as that for scaling a development code base: duplication, clunky and/or complicated setup, inconsistent conventions, etc.  In essence, good automated regression test suite practice is about good development practice.Tests are a product asset.  They are a maintenance deliverable to make subsequent changes easier.

Because tests clearly communicate how a product behaves, they help with both the design and verification of subsequent changes.  An executable test suite (including data and environment dependencies) should be an expected part of a delivered product, not something that is used and thrown away after a project ends.Automated testing is not enough.  You also want ongoing exploratory, sapient testing.

Machines are good at inspecting for known expected behaviour.  Humans are good at exploring unexpected behaviour.  Human testing should focus on improving our understanding the boundaries and attributes of the solution space to help inform the design and development of future solutions.
Categories: Blogs

What question is your MVP asking?

N. Taylor Thompson wrote a blog post on building Minimum Viable Products that I was told was interesting but difficult to get through, so here's my attempt at an easier expression of the ideas:

----
A business model is a set of assumptions.Minimal Viable Products (MVPs) are the experiments used to either validate or invalidate the assumptions in a business model.
Every MVP should be asking a question.  The answers affect the next step you take.What question is your MVP asking? What does the answer tell you?

If the answer doesn't affect your subsequent behaviour, why did you bother asking the question? That is, if the next step doesn't change depending on whether the MVP succeeds or fails, then the MVP was a waste of time.
Different types of MVPs provide different types of answers.Your MVP can be worse than the final productThat is, not as slick, handicapped in some way, but still contains the essence of the solution.

SUCCESS: Indicates that you have a strong problem-solution fit

FAILURE: Could be because the concept is flawed OR it could be because the product isn't good enough yet.

N. Taylor Thompson calls this a Validating MVP.
Your MVP can be better than the final product.This is the essence of the Concierge MVP approach. Create a better product at an unsustainably high cost by personalising for every customer.  In essence, deliver magic and see if enough people are interested.

SUCCESS: Indicates that you have a market for your product, though you need to work out how to be profitable.

FAILURE: Time to pivot or move on.

N. Taylor Thompson calls this an Invalidating MVP.
Start with a Concierge MVP, follow-up with validating the details of the business modelN. Taylor Thompson suggests that for any situation with significant market risk, the most effective approach is to start by asking whether there is a market if the solution was magic, that is, with an MVP better than the final product (aka "invalidating MVP"). This is a more efficient way of detecting whether you're solving the right problem.  Only if that is successful should you worry about validating the other assumptions of the business model using MVPs that may be worse than the final product (aka "validating MVPs").
Categories: Blogs

R/plyr: ddply – Error in vector(type, length) : vector: cannot make a vector of mode ‘closure’.

Mark Needham - Mon, 07/07/2014 - 08:07

In my continued playing around with plyr’s ddply function I was trying to group a data frame by one of its columns and return a count of the number of rows with specific values and ran into a strange (to me) error message.

I had a data frame:

n = c(2, 3, 5) 
s = c("aa", "bb", "cc") 
b = c(TRUE, FALSE, TRUE) 
df = data.frame(n, s, b)

And wanted to group and count on column ‘b’ so I’d get back a count of 2 for TRUE and 1 for FALSE. I wrote this code:

ddply(df, "b", function(x) { 
  countr <- length(x$n) 
  data.frame(count = count) 
})

which when evaluated gave the following error:

Error in vector(type, length) : 
  vector: cannot make a vector of mode 'closure'.

It took me quite a while to realise that I’d just made a typo in assigned the count to a variable called ‘countr’ instead of ‘count’.

As a result of that typo I think the R compiler was trying to find a variable called ‘count’ somwhere else in the lexical scope but was unable to. If I’d defined the variable ‘count’ outside the call to ddply function then my typo wouldn’t have resulted in an error but rather an unexpected resulte.g.

> count = 10
> ddply(df, "b", function(x) { 
+   countr <- length(x$n) 
+   data.frame(count = count) 
+ })
      b count
1 FALSE     4
2  TRUE     4

Once I spotted the typo and fixed it things worked as expected:

> ddply(df, "b", function(x) { 
+   count <- length(x$n) 
+   data.frame(count = count) 
+ })
      b count
1 FALSE     1
2  TRUE     2
Categories: Blogs

XM Principle 7: Continuous Integration Development.

Scrum Breakfast - Mon, 07/07/2014 - 07:59
WIKISPEED has team members contributing in 20+ different countries, any time of the day, with variable availability. How does they produce a cohesive, salient product? The answer has two parts, the first part is about engineering practices, and the second about how to scale.

At the engineering level, Extreme Manufacturing employs Continuous Integration Development (CID) to run their test suite frequently (see principle 3, Test Driven Development). Continuously Deployed Development (see principle 8) ensures a tight collaboration between product creation and product manufacturing, so the goal of never being more than 7 days from releasing an improved product can be achieved.

Continuous Integration Development (CID)  ensures that the test suite is automated as much as practical, so that every time a team member sends in an updated design, an extensive test suite is run automatically.

Every time a team member uploads a new 3d drawing to DropBox, Box.net, Windows SkyDrive, or any of the file sharing technologies in use, WIKISPEED run tests. WIKISPEED can simulate crash tests and stress tests on the part using FEA (Finite Element Analysis) and a software package like LS Dyna or AMPStech. WIKISPEED can simulate airflow, aerodynamics, fluid flow, heat transfer, and electrical propagation using CFD (Computational Fluid Dynamics).

These tests can be run automatically whenever a new CAD shows up, and write out a 1 page report with a list of red or green lights. Green lights mean the test is same or better than the current version, or passes an explicit test for that part or module.

In this way, team members from all over the world can simultaneously contribute in parallel with very different ideas for improvements to each module. And it’s easy to know what the current best part is; the version of record is whatever part in CAD has passed all tests with the most green lights.

WIKISPEED includes tests for simplicity and low cost, along with user ergonomics, maintainability, manufacturability, and conformance to interface(s) of the module they are a part of.

Next: XM Principle 8: Continuously Deployed Development

The 10 Principles of Extreme Manufacturing

After an unexpectedly long break, I am now finishing up the series on Extreme Manufacturing! This post was written by Joe Justice and Peter Stevens.
Categories: Blogs

Drei Argumente für Scrum in der Hardware

Scrum 4 You - Mon, 07/07/2014 - 07:30

Als Takeuchi und Nonaka vor bald 30 Jahren das Wort “Scrum” für Produktentwicklung in den Mund nahmen, dachten sie an alles außer Software. Ihre Referenzen waren 3M, Canon und Fujitsu – allesamt Hersteller von physischen Produkten. Und doch stand die Jahrtausendwende ganz im Zeichen der agilen Softwareentwicklung.

In den letzten Jahren beobachten wir eine Trendwende. Unternehmen in hoch innovation Branchen wie Medizintechnik, Automobil oder Sensorik und Messtechnik stellen auf agile Entwicklung um. Der Grund dafür liegt auf der Hand – diese Unternehmen stehen vor ganz ähnlichen Problemen wie die Softwareentwicklung damals:

  • Die Entwicklungsgesschwindigkeit kann mit dem Veränderungstempo am Markt nicht mehr mithalten. Früher konnten Konzepte monatelang ausgearbeitet, bewertet und dann wieder überarbeitet werden. Bis die Entwicklung anfing, konnte viel Zeit ins Land gehen. Heute gilt: Je früher sich ein Konzept als unmachbar erweist, desto besser. Deshalb setzt Scrum auf die Verifikation des Designs innerhalb von kurzen Iterationen, etwa anhand von Prototypen oder virtueller Integration der Baugruppen. Indem Konzept und Entwicklung Hand in Hand gehen, können Holzwege schnell identifiziert werden – das technische und fachliche Risiko wird nach der Devise “fail early and often” ganz zu Beginn angegangen.
  • Außerhalb der Projektwelt gibt es die wirkliche Welt – und diese hat die dumme Eigenschaft, sich nicht immer an Lasten- und Pflichtenheft halten zu wollen. So enstehen selbst spät im Projekt noch neue Anforderungen, die viele Seiten eines sorgfältig ausgearbeiteten Konzepts obsolet machen können. Mit Scrum machen wir das anders: Das Product Backlog listet alles auf, was für das Produkt gebraucht wird. Auch die Rahmenbedingungen (z.B. die Größe des Gehäuses, die Anzahl der Buchsen oder der Preis) sind dort bisweilen akribisch genau fest gehalten. Und dennoch ist das Product Backlog kein abschließendes Dokument. Alles, was zu Beginn noch nicht geklärt sein muss, wird bewusst offen gelassen, um es dann vor der Implementierung im Detail festzulegen. Kommen also neue Anforderungen dazu, die die Rahmenbedingungen nicht wesentlich verletzen und auch keine größeren Umbauten erfolgen, sind Änderungen ein leichtes Ding: Das Backlog enthält einen neuen Punkt, der dann zur gegebenen Zeit mit dem Team spezifiziert wird.
  • In einem Punkt sind die Softwareentwickler uns voraus: Durch Testautomatisierung auf Systemebene können sie jede Veränderung sofort auf ihre Auswirkungen für das Gesamtsystem prüfen. Das ist in der Hardware schwieriger. Dort werden Modifikationen häufig nur modular getestet – erst zum Schluss, wenn Änderungen am Prototypen kaum noch bezahlbar sind, ist das Verhalten des Gesamtsystems verifizierbar. Scrum sagt hierzu: Suche dir ein Team, das gemeinsam in der Lage ist, das Produkt in nur zweiwöchigen Iterationen selbständig weiter zu entwickeln. Das bedeutet, dass ein Entwickler auch Konstrukteur sein muss – und umgekehrt. Das bedeutet auch, dass Mechanik und Elektronik Hand in Hand arbeiten müssen, damit sie das Zusammenspiel der Komponenten in Echtzeit verifizieren können. Ähnlich eng muss die Verzahnung zwischen Firmware und Elektronik bzw. Hardware sein. 3D-Drucker und Fräsmaschinen erlauben die schnelle Herstellung von Prototypenteilen. Mit Open Source Hardware kann schon heute auf eine Reihe von existierenden Designs für Testzwecke zurück gegriffen werden. Das agile Hardware-Labor ist eine der großen Herausforderung für Scrum in der Hardware.

Literatur:
Takeuchi, Hirotaka und Nonaka, Ikujiro: The New New Product Development Game. Harvard Business Review, January February 1986.

http://www.visionmobile.com/blog/2014/02/learned-built-hardware-agile-way/

Wer hat Angst vorm ersten Wurf?

Related posts:

  1. Agile Hardwareentwicklung mit Scrum
  2. Wer hat Angst vorm ersten Wurf?
  3. Releaseplanning 10 Tipps

Categories: Blogs

The Role of Middle Management in an Agile World

When discussing Agile roles, there is much written about the Scrum Master, Product Owner, Development Team, and Customer.  But there is little written about what the Middle Manager should do in an Agile World.   Note, when I talk about Middle Manager, I am talking about the Line Manager, Functional Manager, Manager, and Director level manager. 
I recently discussed the middle management roles within an Agile context to several different middle managers.  They each had an interesting perspective on what it was like when their teams became Agile.   Here are two excepts:  
  • The Functional Manager who was also the team's Line Manager noted that they spent much less time on directing the team on what to work on since the work was now coming out of the Product Backlog.  I told him that yes this is big adjustment.  He needed to focus on ensuring that his team members had the right skills, understood the Agile principles, and were given the education they needed to become a fully cross-functional team.
  • In talking to a Director who now has 3 self-organizing teams, she was telling me that she was having a hard time knowing what to do since she felt she had to get more hands-on.  I told her by backing off, helping educate the team members around their new roles, and then allowing the teams to self-organize around the work was the right thing to do.  She needed to provide more vision level focus to connect the organization’s strategies to the product visions.  She commented that this was very different from the more traditional management role she had been used too.  

Ultimately, it is important to understand that middle management are critical to the success of an effective Agile deployment.  They are the lynchpin between the executive’s vision for Agile and middle management's willingness to allow Agile to thrive on a team. If they are engaged and buy into Agile, then the change may succeed. Even when executives buy in, if middle management does not do likewise, they can block a team's ability to succeed with Agile.    

If middle management don’t understand their role in the new order or feel threatened by the change, they may become Deceivers or Deniers and block the success toward Agile. Because of this, it is critical that middle managers are educated on Agile at the same time their teams are
Middle management must adapt their role and learn to gently back away from their functional leadership, act more as servant leaders who trust their teams, help them remove roadblocks, and support the agile principles and practices. They may attend the Sprint Review to see progress of the working functionality and the Daily Stand-up to gain a sense of team progress.   Middle management must also learn how to establish the concept of bounded authority where teams can make their own decisions and commit to their own work. The balance is that managers keep limited responsibilities to provide a vision and support their staff, while allowing teams ownership of their work.  Finally, middle management must be willing to be transparent about what is going on in the organization and be willing to communicate this information to the team. 
Other Roles that may suit Middle Management
Often middle management have less to do in an Agile world. The good news is that they may consider options such as changing their role to Resource Manager, where they manage more people but do not own an organizational functional area. They may consider a Product Owner role if they have been engaged in collecting requirements and interacting with customers. Although this role should no longer be managerial (i.e., not direct reports), a PO helps shape the product by collecting and grooming the requirements and collaborating with the team.   They may also move to another Functional Manager role where there is still a need for this role.  And some will remain their current middle management leadership roles.  If they continue to want to do the more traditional middle management roles, they may consider looking for companies that continue to look for the more traditional roles.  
How Middle Management can evaluate themselves in an Agile World
Here are a few questions middle managers can ask themselves to see how aligned they are in managing teams in an Agile World.
  • Are you allowing for self-organizing teams while still providing servant leadership? 
  • Are you removing command and control elements while providing bounded authority?
  • Are you supporting the Agile values and principles starting with marshaling a culture toward delivering value?
  • Do you remove the language of false certainty, big-up-front planning and requirements, and big batches?
  • Do you remove the significant roadblocks that hinder an agile team’s progress?
  • Do your teams perceive you as a coach and leader more than as a manager?
  • Are you helping the team with supporting their people and equipment needs?
  • Are you adapting the performance objectives to support team accomplishments to ensure they are delivering the highest value?
  • Do you help the teams when they have external team dependencies in order to get their work done?
  • Are you fostering a learning organization?  Do you provide teams the time to get educated (training, coaching, etc.)? 

Categories: Blogs

Call for Participation: Product Owner Camp Switzerland #POCampCH

Scrum Breakfast - Sun, 07/06/2014 - 14:19
Following the fantastic Swiss Agile Coach Camp, I thought it would be cool to organize a similar event around of Product Ownership. I put out a tweet and got some good resonance (so much that it is now difficult to keep track of everyone who responded),

The Product Owner Camp in Switzerland #POCampCH will be a 2 day open space event. It is a non-profit community event and this will be reflected in the prices.

I expect it will be held during the first or second quarter of 2015, that it will be in some nice location in the mountains, or at least away from a city, and I expect there will be one or more some optional workshops on Product Ownership around the event.

With this call for participation, I am looking to confirm these expectations, find out who wants to come, who is willing to contribute, and get some guidance for key decisions about the venue and possible non-open space program (workshops or courses).

Are you interested in participating in or organizing the open space Product Owner Camp Switzerland? Sign up below!

Loading...
Categories: Blogs

Five links on Large scale agile

Agile at scale requires Trust at scale!

@HenrikKniberg in great keynote “Culture > Process” at #sgcdg

henrik.signature

 

 

 

I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.


Categories: Blogs

Deliverables is NOT the first thing you should worry about

When I talk to governance people about Agile, the first questions they have are typically about deliverables, and specifically documents.  If you're unwary, this is where you might get drawn into a "Does Agile mean no documentation?" "No it doesn't" debate which mostly misses the point.
The issue is not about what deliverables method X has vs method Y.  The issue is how one should think about methods.
If you want to understand a process, the priority is:
  1. Outcome
  2. Activities and how people interact
  3. Artefacts and outputs
The problem I have is not so much about what deliverable your Agile process should have or not.  The problem I have is that you started the discussion with the lowest priority issue (artefacts and outputs) rather than the highest priority issue (outcomes).
Categories: Blogs

Enterprise Agile Transformation through Centralized Agile Group – Benefits and Challenges

Agile World - Venkatesh Krishnamurthy - Sat, 07/05/2014 - 03:36

Authored the following article for Cutter Consortium as part of their Agile advisory series.  In this article, some analysis has been done detailing pros/cons of setting up centralized Agile excellence or group to promote Agile as part of Agile transformation in the enterprise.

Here is just a snippet and the complete article can be accessible by  Cutter members.

image

Read rest of the article on Cutter

image

Categories: Blogs

Shaping culture through inaction

Doc On Dev - Michael Norton - Fri, 07/04/2014 - 16:32
I follow Dan Rockwell on twitter. His handle is @leadershipfreak and he tweets quite a bit of good leadership content. If you don't follow him, I recommend you give him a look.

Dan sent a tweet out about how reinforcing behaviors builds organizational culture.
Behaviors you model, affirm, and reward build organizational culture.
— Dan Rockwell (@Leadershipfreak) July 4, 2014 I agree with the tweet. I retweeted it.

The only thing necessary for the triumph of evil is for good men to do nothing by BK, on Flickrhttps://www.flickr.com/photos/pictoquotes/10476531225It got me thinking. It is not only the things we reward that shape culture, but the things we allow. Perhaps the easiest way to shape a culture is to do nothing at all.

When a rockstar employee yells at, denigrates, or refuses to help teammates and you let it slide because the rockstar is valuable, you are shaping a culture. When a teammate tells a racist or sexist joke and you say nothing because nobody present is a member of the target group, you are shaping a culture. When an executive abuses power, when a coworker engages in gossip, when a team cuts corners to make deadlines and you decide it isn't your problem, you are shaping a culture.

What appears to be inaction is still an action.
Categories: Blogs

News update 2014/07 – Learn how to lead self-organising teams

ScrumSense.com - Peter Hundermark - Fri, 07/04/2014 - 13:28

Companies doing agile transformations must empower their development teams or Product Owners to say no. No is important, it is also very final. It implies that you can’t have whatever it is that you want. That is not an answer that Product Owners, trying to keep customers happy can go back to their customers or […]

The post News update 2014/07 – Learn how to lead self-organising teams appeared first on ScrumSense.com.

Categories: Blogs