Heynemann – Just another dev

Introduction

Jidoka, also known as “intelligent automation” or “automation with a human touch”, is lean’s way of automating repetitive tasks.

This time we join the INews team as they try to define how far to go with automating or not repetitive processes.

Autonomation

John – Hey guys! How was christmas?
Jane – Pretty good! Yours?
John – Really cool. What about the rest of you?
All – It was great!
Christian – We’ve been talking a lot about lean concepts and I’m not that familiar with lean methodology. Whenever I don’t know something I yearn to learn it. I’ve spent all my free time in the last weeks studying it. One thing that comes over and over is autonomation. That is a kick-ass concept!
Jane – Autonomation?
John – Yeah Jane. Autonomation means automation with intelligence.
Jane – What do you mean “with intelligence”?
John – Well, machines lack intelligence, right? That’s why it’s called artificial intelligence. So automation with intelligence means automation with humans involved. It means automating to become more efficient. It means automating well-known repetitive tasks.
Jane – Oh. I see.
Susan – I think we do that already, right? Our build is automated, for one. Oh! Our tests are automated as well! Hmm… I see your point! We could build and test our app ourselves. We just automated it so we are more effective. We didn’t replace ourselves for a machine. We are using it to help us!
John – Exactly. Still, I think we are not aggressive enough with autonomation. Susan, when we finish stories, what do you do to help us accept them?
Susan – I verify the results versus my mock screens to see that you got the proper sizes, margins, etc.
John – And that’s pretty repetitive, isn’t it? That’s something we could come up with a creative way of automating. Joseph, you perform a lot of exploratory testing as well don’t you?
Joseph – Yes I do, but how can you automate exploratory testing, which is by definition human?
John - Hmm… We can’t automate exploratory testing. What we can do is automate the tests you perform every time. We could come up with some strategy to record the tests you do and automate those. This way, every time you did exploratory testing we would end up with a richer testing suite.
Joseph – I see. Well, I guess we could be more aggressive about autonomation.
Christian – So it seems like a team value, doesn’t it? Automating things to improve our effectiveness.
Joseph – Indeed it does, Christian. Indeed it does.

Conclusion

There’s a big emphasis on not automating things with the intent of replacing humans. The goal of jidoka is to make humans more effective and aid them in detecting problems early and often.

Whenever something can be automated to improve the team’s capacity to respond to change, it should be. The automation should not happen before the actual way of doing things is well-known to the people involved. This is paramount so the automation has the proper goal (as outlined above).

Introduction

The INews team has reached an important milestone. Four of the team’s values are defined and understood.

This time they are talking about a very controversial topic: product ownership.

Who owns it?

John – Hey! How are you all today?
All – Good!
John – I was reading an awesome article last night. It was so good I felt like calling you guys immediately.
Susan – What was it about?
John - About product ownership. The idea here is that you push product decisions as close to the people working with them as possible. The company is responsible for setting the context that allows those people to decide.
Jake – What do you mean by context?
John – The company is responsible for setting strategies and broad scope goals, as well as providing the team with whatever other intel they might need – financial, internal, market share, marketing, you name it. If the team needs that information, they should get it.
Christian – Ok, I totally agree with that. I’m still wondering about the ownership part, though.
Susan – In the last event I attended, Wackile – agile for the wacky – I saw a brilliant presentation about how projects are killing agile initiatives. Projects are tricky beasts. They have start, finish and handover. At first there’s nothing wrong with that, except there’s no incentive whatsoever for developers to choose long term decisions. They’ll be long gone by the time their decisions affect the product.
John – I see. Well, Chris, what I meant with ownership is that we as a team should be the ones deciding where the product should go. Not someone with no context about the intricacies of the product. What Susan just pointed out just reinforces the need for the people working with the product to feel part of it.
Jane – I couldn’t agree more. As an experience designer I get to decide quite a few things about the product. Sometimes, though, I wish the team had more freedom to choose their own path.
Joseph – I’ll get Daniel here as I believe he’ll be able to tell us whether this value is aligned with the company’s values.

Ok, you guys don’t know Danny, but he’s a great CIO at Acme. He really fights for his teams, in order to provide them with the best possible work environment.

Daniel – What’s up guys? What can I do to help you?
John – Hey Danny. Thanks for joining us in so short notice. The thing here is we decided as a team that one of our values is that we want to own the product in the lean sense that we get to make product decisions…
Daniel – While the company sets the context, right?
Joseph – Right.
Daniel – Perfect. No problems with me. I’ll get our CEO buy-in. As a start is there any intel I can help you with?
Susan – Hi Danny. Actually, there is: Other news companies’ market share on mobile news delivery.
Daniel – I’ll get you guys that info asap. Now I gotta run. See you all. Take care.
All – See ya!

“What a great guy!”, I think to myself.

Joseph – I guess we just got another team value: we own the product and we’ll take care of it thinking about the long run.
Me – IMHO this was the best meeting so far. Danny is the best.
Joseph – That he is, Bernardo. That he is.

Conclusion

The people who are more qualified to make important product decisions are the same ones working with it on a daily basis. They know all of its intricacies and constraints.

Why risk having someone that does not fully understand the issue deal with it?

Yet, most companies keep pulling decisions up in their hierarchies, trying to protect their products from the poor judgement of their employees.

Not trusting the people doing the work to make decisions results in shallow decisions and lack of commitment by the people working with the product. Short-term actions are made, the product evolves in unintended (and bad) ways and eventually people want to get out of the product team. At some point a major redesign and rebuild is needed.

Have you guys ever seen this?

Introduction

The last time we met with the Acme INews team I was telling you guys how they came to the conclusion that if you don’t release it, you lose it. Ok, I’m just kidding, but they all agreed that unreleased code is waste and that it was a value for all of them to diligently work on reducing cycle time variation.

This time around we touch a subject that most companies (well at least some of the ones I know of) don’t like to discuss. Respecting your employees as you expect them to respect you, and allowing them to have fun. Yes, that’s right, FUN! Let’s see what the INews team thinks of that.

Respect

Jane – Hey guys. I wanted to talk to you about something since we first met to do this job.

John – Sure Jane, go ahead. I think we must maintain an open channel for communication at all times if we are to succeed as a team.

Jane – Thanks John. Well, sometimes in my previous projects I got the feeling of being an outsider among developers. I heard comments about how I was being picky and annoying. That made me feel very bad and in those projects I feel like I contributed less than I could because I was afraid of that behavior.

Jake – Jane, that’s a very good thing to discuss. As a client-side developer I heard comments in these areas as well. After discussing with the devs and explaining to them my point of view, things worked out quite alright, though.

Jane – Yeah, it might be so. Even so I still think I shouldn’t have to do that. If we are in a team we trust each other and respect each other’s point of view, right?

John – Absolutely right! There can be no better opinion or prevalent point of view. If we are a multidisciplinary team, we should value each other’s opinions above all and treat each other as we want to be treated in return.

Susan – No offense, guys, but sometimes I feel the designers take our opinion for granted as well.

Jane – Hmm… I see… Can you ellaborate, Susan?

Susan – Sure. Sometimes a designer comes up with an user experience that’s great. It really is. I can see myself loving that experience. It just isn’t realistic given our constraints (might be hardware, network, you name it). Usually I approach the designer and explain that. A lot of times I got a “it’s not my problem” look and had to resort to my boss for help. I would say I didn’t get the same respect I was showing for that professional.

Jane – Sure you didn’t. Well, I guess it does go both ways, doesn’t it?

Joseph – I’m pretty sure we can get along if we just try to always see the other person’s point of view and treat them with the same respect we expect them to show towards us,  don’t you agree?

All – Yep.

I keep getting amazed by how simple they make these things look.

Christian – I’d like to discuss a related topic. When I’m contributing to some project or even coding one of my own, usually I have a purpose to fulfill (I need the feature, someone at work does, or I just find it cool). Even though I have a purpose, if it’s not fun, I won’t do it. No matter how much I force myself to do it, I just won’t.

There will be something else that is a lot more fun to do, or I’ll go read something. I was wondering how can we make sure working in our project is fun. How can we enjoy that feeling of “Great!!! I’m going to work today!” when we wake up?

John – I don’t think there’s one right answer for that. I believe it’s a set of things. A great project makes we want to come work on it (the cool tasks as you said). A great environment where we respect each other does that as well. We already have our XBox 360 and our foosball. How do you guys feel of ‘do whatever you want’ friday?

Christian – What do you mean?

John - Every two or three fridays we’ll get a free day. We can code whatever we want, with whomever we want. We can study, experiment or just play a game together. Anything that improves our project in any way whatsoever.

Susan – That’s a very interesting idea. Can we refactor our own product’s code or implement a feature we’d like to see int he product?

John - Sure. Anything we want.

Jane – Could I use that day for discovery and experimenting with different things?

John - Of course! Anything that you think will help!

Jane – Ok, can’t wait till next Friday!!!

Joseph – I really love that idea. I think we are set in two VERY intertwined values. Might be the same value altogether. Respect and Fun with responsibility. Meaning that we’ll respect each other and have fun together, while delivering business value to ACME. Is that about right?

All – YES!!!

Me - Ok, again with time to spare, and it’s about time to go. Anyone for a settlers game?

Conclusion

Several companies (like Yahoo, JotSpot, Atlassian, Facebook, Google, Atom and Technorati), have already found that by letting your employees self-organize and make their own decisions about the product they are working in pays out big time.

Having a fun environment is not only a bonus to productivity. It is a requirement for creative skilled workers to unlock their full potential. Companies that keep trying to control what their employees are doing (via timesheets, task monitoring or metrics) are in fact killing the motivation that could trigger incredible features to their products.

A product team must be kept in a fun, respectful environment where they can decide what they want to do instead of being bossed around. This way, they’ll be working in the product in their free time, because they want to do it.

There’s a very good video by Dan Pink about what motivates us. Basically it’s authonomy, mastery and purpose. You can learn more by watching the video. I VERY DEEPLY recommend it. It really changed my way of seeing some things.

Introduction

In our last installment, we learned that the INews team decided to never let problems grow and instead solve them as soon as they appear. They also decided on having a formal way of solving problems, so that they (and the rest of the company) may benefit in the future.

This time we accompany them as they discuss a topic that is very near to my heart: Delivery.

Release or not Release, that’s the question

John – Morning all! We had a very productive day yesterday, now didn’t we?

All – Yep.

Susan – I’m sooooo sleepy, John! (*chuckles*) Yesterday I went home thinking about some values that I hold dear. I’m not sure this is the time to discuss it, but I really enjoy delivering business value. I’m filled with joy when I realize that my work is helping our coworkers in being more productive RIGHT NOW. How do you guys stand on this?

John – Well, when you study Lean Manufacturing, you learn all about delivering, since they consider anything that is not being used by a customer or adding value to a product to be waste. So, if you are a factory worker, your sole purpose is to drive the product as fast as possible to a client. Please note that as fast as possible takes into account every single quality factor that the customer expects.

Christian – I have a lot of experience in delivering, but we call that releases in my projects. I release as often as I can so I can gather feedback from the community. It is also a very good idea to release as much as you can to minimize the amount of work that goes into a release.

Jake – I don’t have much experience in this area, but something tells me that releasing often makes a lot of sense. I was just wondering how the big guys do it: JQuery, Django, Apache and other projects like that. How do they release?

Christian – I’m not sure how they do their releases, but I love apache’s concept of a release: “Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released.” [1]

John - Yeah, couldn’t agree more. You should release as much as makes sense. Unreleased code sitting in our laptops does no good to our clients.

Jane - Well, when I design a user experience for a product, I have to think a little ahead about how our users are going to interact with it. Imagining their experience is in no way a substitute for learning how they are actually using it, so I too consider it to be crucial to have customers using our product as fast as we can, even if we have to cut a little bit on the feature side.

Joseph - Funny thing, I just purchased Continuous Delivery, a book that was just released (no pun intended). This is one of my favorite subjects. I do believe in continuous delivery. As soon as we mark features as complete, we have them in production. Lean Manufacturing introduces a measure called cycle time, which means the total time between a customer requesting something and the customer getting to use it. What I understand we just agreed, is that we will work diligently to reduce our cycle time as much as we can.

John - That sounds about right!

Me – Once more with time to spare! Let’s play some foosball.

Conclusion

Sometimes we are working in something really cool in our projects. Sometimes we are just fixing stuff. The point here is not what we are doing. It’s who’s benefiting from it.

If you are building software I assume that someone is going to use what you are building. If that’s the case, until that customer starts benefiting, your code is waste.

Cycle time is a very interesting measure, in that it measures your turn-around time to new features, as much as your responsiveness to issues that you or your customers find in the software.

From Wikipedia:

Cycle time variation is a proven metric and philosophy for continuous improvement with the aim of driving down the deviations in the time it takes to produce successive units on a production line.^[1] It supports organizations’ application of lean manufacturing or lean production by eliminating wasteful expenditure of resources. It is distinguished from some of the more common applications by its different focus of creating a structure for progressively reducing the sources of internal variation that leads to workarounds and disruption causing these wastes to accumulate in the first place. Although it is often used as an indicator of lean progress, its use promotes a structured approach to reducing disruption that impacts efficiency, quality, and value.^[2]

In my humble opinion, the best thing about cycle time is that it is a TEAM metric and not an individual one. That means that if the team collaborate to improve work and reduce waste everyone benefits from it.

Introduction

So far our team has decided on a set of values and we saw how they discussed the first one.

Now we join them as they get back from Starbucks to discuss again their values.

Problem Solving

The meeting starts again and once more I’m in charge of keeping time. John starts:

Credits to Ell Brown

John – Hi guys! Welcome back! That was a nice coffee break. There’s something I’ve been thinking about and I’d really like to talk with you guys about.

I would like to discuss how each of you feel about problem solving. If we are to keep continually improving we need a systematic way of solving problems. At least that’s how I feel.

Jake - What do you mean by systematic?

John - I mean we need some way to archive the knowledge we gathered and the solution we had for each problem. This way we don’t need to repeat ourselves when solving the same problem, or even when some other team in the company wants to solve it. I read about how Lean companies do it with A3 report cards and I really liked what I read.

Susan - Even though I never worked with a formal way of solving problems, I often thought that we should have a way of publishing our findings when we decide something.

Christian - Can you give an example?

Susan - Sure. In my last project we were using Python as our main language. Some team members had experience with Django, while others preferred to use a more low-level framework like CherryPy. Preferences aside, we were expected to provide real-time dynamic data to more than a hundred thousand concurrent users, so performance was a key constraint for us.

Jake - Wasn’t there a benchmark you could use to decide?

Susan - We didn’t find one, so we ended up doing a thorough comparison of some Python Web Frameworks with many different production settings (Apache, Nginx, you name it). The results pointed us in the right direction.

The thing is that even though it was very cool to learn all that on a personal level, I feel that we didn’t leave behind any trail of this knowledge to other teams. Probably others have done this already, as was reported by our production team. If we don’t have a formal way of solving problems like this, we are bound to repeat this effort time and again.

John – I couldn’t have summarized it better. Thanks Susan for explaining what I meant. That’s exactly it. Knowledge generation is a problem that I really care about. What about you guys? What do you think?

Credits to Dan.

Jane - We have that in the Design team. We always leave behind reasons and the discovery made to achieve a certain standard. I thought that you guys did that as well. I most certainly think we need to standardize how we decide things. This is key even within our team.

Imagine me and Christian finish some UI definition together and we want to share with you guys. I expect that you’ll want to know what were the assumptions and everything that led us to define the UI in the way it was defined, right? In order for that to happen there needs to be some mechanism to formalize knowledge. I really like this A3 thing, since I love sketching with pen and paper.

Christian - I don’t have much to add except that whenever I work in Open Source Projects, each project has its own way of preserving knowledge. Wikis, evolution proposals, docs, release notes, you name it. The key thing is that all successful projects share this trait in common. They all keep their knowledge at heart. I think we should do the same. I’d realy like to try this A3 technique, if we can change it later if we don’t like it.

Joseph – Hey, that’s brilliant. We agreed already on changing any process that does not work to something better, didn’t we?

All - YES!

John - Ok, we have a way to solve problems, but how are problems going to affect our work. I hear Susan has already worked here in the company using Stop the line methodology, right?

Susan – Yes, I did. And it was GREAT! The team used the motto: “The best time to solve a problem is RIGHT NOW!”. I learned later that this translates to the Jidoka principle in LEAN methodologies. It means that whenever we have a problem we stop working in whatever we are working to solve that problem. It seems counter-intuitive, since we’ll be “less” productive due to solving problems. The thing is even though this slows us down a little in the beginning, it speeds us up GREATLY in the long run.

Christian – What about bugs? Do we keep them in a bug tracker?

John - I reckon that if we keep solving bugs whenever we find them or whenever people report them, we should have 1 or 2 bugs open at any given time tops. Who needs a tracker to track 1 or 2 items?

Christian - Makes sense.

Joseph – So we as a team agree that whenever a problem arises the proper number of people in the team should stop as soon as possible to fix it and then find a way (at first an A3 report) to leave behind the knowledge on how it got fixed and why. Is that it?

All – Yep.

Joseph - Ok, I think we got our second value. The best time to solve any problem or defect is now.

Conclusion

Software Craftsmanship is a creative activity. As such we are confronted with problems and issues every day. It seems to be a good thing to just archive the issue in some way (bug tracker, tech debt card or any other way you can think of).

The problem with this is that the issues start building up and work starts to slow down. If you keep stopping the line whenever you find a problem, eventually the number of issues will decrease astoundingly. When the number of issues decrease, the speed of the team increases.

Refactoring code is one way to stop the line whenever you see code that is not clear. Fixing a bug you found while on another story is a way to stop the line. Acting on an integration problem with the customer is a way to stop the line. Introducing an improvement in the process is a way to stop the line. Anything that solves any problem RIGHT NOW is a way to stop the line.

There must be a way of publishing the results of problem solving in a way that people can benefit or refer to in the future. This leads to a better knowledge management and improved collaboration within the company. One suggested way of doing this is how scientists currently do: the scientific method. Since I already discussed it, I won’t say anything further.

If anyone has any suggestions on problem solving or stopping the line, please leave comments.

The Value

As explained in the previous post, the first value outlined in the iNews team is that processes serve the sole purpose of being challenged and improved.

The Discussion

The team gathered at a meeting room. At the meeting there were John Miller, Susan Lawrence, Jane Collins, Jake Preston, Christian Fields, Joseph Ross and me.

I was invited just to listen, no talking allowed. I was in charge of time keeping so they would respect the time box for the meeting (the only thing I was allowed to say).

The first one to speak was John:

John: Hi guys! It’s a pleasure to be working with such a distinct and diverse team.

We have a very ambitious and interesting project ahead of us. We are in charge of changing the way people think about mobile news.

But before we set out to do just that, I’d like to discuss with you our team values.

All the other team members looked puzzle. Susan quickly replied:

Susan: I don’t get your meaning, John. I thought we were supposed to use scrum like the rest of the company.

If we are to use it as a process then we already know our values: the twelve principles in the agile manifesto.

What exactly do you mean by “our values”?

Every pair of eyes in the room turned to John. Tension in the air (ok, that’s just me being dramatic):

John: Very well observed. The issue here is that those are the agile manifesto principles. Not OUR principles.

We might end up with exactly the same set of principles, but then they’ll be our principles as well.

If we get to that, I’m sure we’ll live by those and in every decision you’ll abide by them.

A sense of shared understanding filled the room. “That makes just so much sense”, I thought.

Jane still looked uneasy, though. John, as a good leader sensed that and asked her what was worrying her.

Jane: Well, as a designer I’m not as used as you guys to a formal process. I’m very used to change, though.

It’s very clear to me that change is a competitive advantage.

John: I see, Jane. It is a good thing that you mentioned the process.

I really believe that processes are guides to help us interact and they serve no other purpose than to be challenged and replaced.

Christian: Coming from an open-source background, I’m very used to challenging and replacing “processes” of all kinds: contribution, releases, licensing.

Usually you get the processes from some other well-known successful project and start adapting them to your project.

Joseph: I like that discussion a lot. I come from a ScrumMaster position in the company from the early days of scrum.

A lot of failed Scrum implementations come from the fact that people get the practices without understanding the principles.

This leads to process paralysis. They won’t change anything in the process even if it gets in their way just because some book says they *HAVE* to do it this way.

John: What do you think now, Susan?

Susan: I couldn’t agree more with you guys.

I never thought that people failed to understand that processes are mutating things.

I always tried to adapt processes to fill my needs.

Jake: Even though I come from a very different background, what you said makes perfect sense.

I do share the concern with Jane, though. What if the current process does not really include us in the loop?

John: That’s exactly why we are suggesting that the process must be challenged and replaced with a better fit.

If ANYONE in the team feels some practice is not worth doing and have ANY better idea we should at least give it a try.

Best case scenario, we get best at doing what we have to do. Worst case, we learn. Looks like a win-win situation to me.

At this point I’m just amazed at how easily people with such different backgrounds connected over an ideal of delivering more.

Joseph: Well, I can confidently say that we have one of our values defined.

Processes are guides that should and will be challenged any time anyone thinks of a better way of doing some practice (or even not doing it at all).

There are no fool ideas or experiments. There are no reprimands to suggesting improvements by anyone in the team.

Does that sum it in an understandable way?

Everyone nods in agreement.

John: Ok, so we abide by this value at all times until we find it to be a poor fit to our team and change it. Ok?

Again happy nods in agreement.

Me: Awesome! Done with 5 mins to spare!

Susan: Yeah, and since I’m hungry, what do you guys say of a trip to Starbucks?

All: YAY!

Hmmm… Caffeine addicted, are we?!

They go happily to Starbucks and then come back to discuss next value.

Conclusion

This value may seem counter-intuitive at first. If I keep challenging a process that means it’s not good enough. What’s the point of having a process if it’s not good enough?

The team’s answer to that is that the process is just the current best practices for delivering value and as there’s no such thing as THE best way to deliver software, they are supposed to be continuously challenged, experimented with, improved and replaced.

They do not believe that any of them know exactly the best way of doing anything, yet they uphold the ideal that together, through iterative refinement they can keep improving the way they do things.

This is the reason for this value. The process is not what’s important. Delivering business value is. The process is just the means to do that.

Introduction

In the last part of the ACME’s iNews saga, John, Susan, Jane, Jake, Christian and Joseph set out to start the product.

They decided that, in order to consistently deliver and provide value to the company, they needed to get their team’s values straight. What do they believed in as a group? What principles and ideals would they uphold and work by? So they got together and after some brainstorming they came to the following Team Values Statement.

Team Values

The following values are what the entire team considers fundamental and is committed to upholding.

1. Every process exists for the sole purpose of being challenged and improved;
2. The best time to solve any problem or defect is now;
3. Code only has value in production. Unreleased code is waste;
4. Respect and Fun, with responsibility;
5. We own the product!;
6. Automate everything you possibly can, except people;
7. Tranparency above everything. No questions can be invalid or taboo.

Mission Statement

They finish their value statement with their mission statement:

• These are our values and we commit to them and to one another.
• We also recognize that our purpose is to create value for the organization.

Conclusion

These values are not something the team “agreed” on, or just accepted. This is a set of common values that they share and will uphold above everything.

There’s a big difference in agreeing with or accepting something and sharing a value with someone. The fundamental difference is commitment. People are committed to their values and this team is committed to the values above.

I’ll explain in detail in further posts every single one of the values they outlined as they discussed (I was invited to the discussion).

Introduction

Tonight I was wondering if I could describe a dream team. I’m not talking about dream team members, since I’ve only worked with very smart and committed people for this last year and a half in globo.com. I’m talking about a fictitious team where people would apply everything I believe a dream team would: profound knowledge, scientific method for problem solving, set-based design, continuous improvement, continuous deployment, iterative discovery, design and development, and some other things.

As is very well put by Mary and Tom Poppendieck in their book, it’s never the workers faults that create bugs, delivery rescheduling or customer dissatisfaction. It’s ALWAYS the system. So the main goal for this team is to make the system as mistake-proof as they possibly can, and then some. Through these posts I’ll try to describe the people, the process and its improvements and a product they are developing.

The Product

The team will be doing an iPhone/iPad app to deliver news to clients of a news agency. It’s creatively named iNews.

The Team

Even though this is a fictional team, I want to describe them (even with pictures – all Creative Commons) so I can translate that PEOPLE are the goal, the main thing. These are the people set to do a FANTASTIC product for my fictitious company, ACME Software.

John Miller

John Miller is the tech lead for iNews. He used to work for a very large news agency and has more than 10 years of experience developing software.

John has a lot of experience with agile practices and lean software development. ACME’s board of directors expect him to lead the team to deliver a surprising, efficient and competitive product.

John has experience with static and dynamic languages, yet no experience with iPhone development. He’s eager to learn all about it, though. He wonders what kinds of architectural issues the iPhone/iPad development model poses.

Susan Lawrence

Susan Lawrence is a senior engineer with the company. She is very knowledgeable of Scrum and in previous projects for ACME she loved the methodology. She feels that something was missing, though. There were some issues identified by the team and yet the team did little to solve them.

She has no experience with mobile development but is very eager to learn as much as she can. User experience is a subject that she cares deeply and is looking forward to working with Jane Collins.

She is the author of Stinks, the Continuous Integration server being used by some teams at ACME, so you can tell that she cares a lot about this practice.

Jane Collins

Jane Collins is the user experience designer for iNews. She has a success track record with the company on several previous products.

She used to decide on  her own what the user experience was supposed to be. This has proven to be the ineffective way of doing this, since the team always had issues implementing what she designed.

In her last project she tried a more tight integration with developers and they provided invaluable insight into what the users might value and what they wouldn’t.

She’s looking forward to the challenges of designing a consistent user experience for such distinct devices as the iPhone and iPad.

Jake Preston

Jake Preston used to be an expert at front-end software development. Tired of this separation of front-end and back-end developers, he decided he would be as knowledgeable on back-end development as everyone else in the company (if not more).

Jake has been studying software engineering practices in general and learning more in every project he´s in. The iNews product has several interesting challenges for him. Among them, the different presentation requirements and capabilities of the devices.

He’s very concerned with how can interface automated testing be done in such devices, as well.

Christian Fields

Christian Fields has just joined ACME. He never worked with news agencies, but has a very good track record with open source projects, being a contributor to large and very large projects.

He has a very strong culture of sharing and contributing. He expects to be able to apply this knowledge to iNews, since collaboration with customers and to some other teams will not only be required, but key to success.

He values second to none automated testing and versioning, being so used to rejecting patches that do not provide automated tests and releasing early and often to gather feedback of the community.

He is VERY excited to be working with a team of smart people in a very promising product.

Joseph Ross

Joseph Ross is the project manager. His role is to remove any impediments that stop the team from fulfilling the values in their value statement (next part).

He has a very strong process background being a certified scrum master and PMP. He thinks methodologies are guides whose only purpose is to be improved and replaced with the new improved process.

He has been in the company for more than 10 years, thus he knows virtually every employee and knows exactly how ACME and its people operate, as well as what the company’s values are.

Conclusion

These are the people who, together, will succeed or fail in delivering an innovative news content delivery application for the iPhone/iPad platform.

More about what their values are in the next post.