This article is a cross-post from the Shopzilla Tech Blog.

The way we build software has changed fundamentally. From waterfalls and schedules to backlogs and iterations, we deliver more – more quality, more technology and ultimately more value.

Still, we sometimes miss the point. It happens every time we focus on progress as a first-order goal.

In the “old days”, a project kickoff would mean an extended brainstorm followed by a “scoping” discussion, ultimately resulting in a schedule nobody believed anyway. Inevitably, the teams would fall behind and since the schedule was our only measure of interim success, the frustrated project stakeholders lost faith in the “under-performing” team.  Well before the software had a chance to succeed, the team often had already failed – ironically not because of bad software but because the team were not clairvoyant.

I argue the real failure was a focus on progress instead of the point.  Even in an Agile/Scrum process, we can easily lose sight of the point if we aren’t careful to measure the right thing.

I’ll give an example from Shopzilla’s recent site redo.

In 2007 we redesigned our site delivery platform.  One of the most important decisions we made was to release our new site one “page” at a time.  This approach, coupled with our ability to selectively meter traffic to the newly released site infrastructure, allowed us to move much more quickly because we could limit our risk by % of traffic.

Sounds great – what went wrong?

Releasing page-by-page was fantastic for momentum and risk management, but as it turns out we never released more than a small percentage of normal traffic to the new pages.  Once we completed the functional development we realized that we had been so focused on incremental releases that we had never performance tested the entire system together.  Did it really matter if each page of the site met its SLA when the overall site did not at full-scale?

To a point, we were following the best spirit of agile development with our incremental releases.  However, “done” for a page – or even for every page – did not mean “done” for the site.  We simply never had to consider the performance of the site while releasing one page at a time.  It’s only after we tested the entire system for the final release (at 100% of scale) that we saw serious performance issues and took another month to fix them.

–

Some argue we did exactly the right thing by only addressing issues (like full-scale performance problems) as they came up.  From my perspective however, the whole point of the initiative was to release our new site to 100% of our traffic.  Missing full-scale system performance until the end was a great example of us getting so wrapped up in our page releases that we forgot the point – the business value of a new extreme-scale site infrastructure.  This goes double given that one of the three goals of the project was 1.5 second full-scale page loads.

You get what you measure, so beware focusing too much on progress when the “point” is what you really care about.  Sometimes this pitfall shows up as a missed design principle like our example above.  Worse, we can find our teams more focused on things like 100% “commitment” rates in their iterations without regard to their actual yield (business value created).

Thought I would move onto another topic besides SOA, so I thought Scrum sounded interesting. For no reason besides the odd sounding name. Apparantly it is “an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration.” This quote and the following are from this site.

What is Scrum?
A variation on Sashimi, an “all-at-once” approach to software engineering. Both Scrum and Sashimi are suited best to new product development rather than extended development. Sashimi originated with the Japanese and their experiences with the Waterfall model. They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style. Realizing that speed and flexibility are as important as high quality and low cost they reduced the number of phases to four — requirements, design, prototype, and acceptance — without removing any activities, which resulted in overlap of the Waterfall phases. Then they made the four phases overlap. (Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice before it). Other companies took Sashimi one step further, reducing the phases to one and calling it Scrum. (A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field).

Applying Scrum
For each Waterfall phase there are a pool of experienced people available, form a team by selecting one person from each pool. Call a team meeting and tell them that they have been selected to do an important project. Describe the project, include how long it’s estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc. Tell them how it’s done is up to them and explain that your job is to support them with resources. Now leave.

Stand by, give advice if it’s requested, and wait. Don’t be surprised if a team member thinks the whole thing is insane and leaves. You’ll get regular reports, but mostly you’ll just wait. At somewhere around the expected time, the team will produce the system with the expected performance and cost.

How does Scrum work?
The first thing that happens is the initial leader will become primarily a reporter. The leadership role will bounce around within the team based on the task at hand. Soon QA developers will be learning how requirements are done and will be actively contributing, and requirements people will be seeing things from a QA point of view. As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything. From the initial meeting, the finished product is being developed. Someone can be writing code, working on functional specifications, and designing during the same day, i.e. “all-at-once”. Don’t be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded. The team will become autonomous, and will tend to transcend the initial goals, striving for excellence. The people on the team will become committed to accomplish the goal and some members may experience emotional pain when the project is completed.

Why does Scrum Work?
The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work. This reduces the need for meetings, reporting and authorization. There is control, but it is subtle and mostly indirect. It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes. Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence, and experience, will narrow the range to one or a few options.

I am really interested in this management technique, and would love to research real world applications of it. Anyone know of a published case study?

Day two is over and I’m lying in my bed, happy but tired, and try to keep my eyes open until I’ll have clicked the “publish” button in ScribeFire.

First things first: Some people said to me that they had read my blog posting on day one. What nearly everybody told me was that they’d had the discussion about either German or English talks in the past. And that they’d had more English talks some years ago. And that it is a strange scenario if Germans talk to an audience of just German people but speak English (and some listeners have difficulties to understand it). Ok, I have to admit: In this case German may be the better option .
Just to make it clear: I respect this decision, result of experiences in the past. I’m sure that this is pretty well thought-out. And I didn’t want to blame people who had made this decision. It was less about criticizing something or someone but more a public reflection on my own personal feelings and thoughts. Personally, I really love getting in touch with an international community and I’d really appreciate it if this also would happen in Germany. Nonetheless, even more than that I appreciate a well-organized conference with happy people on it – and that’s what XP Days Germany seem to be.

Anything else? Oh, yes, there were some sessions today – two dozens in four parallel tracks, to be precise. I attended “Creating Leaderful Teams to Achieve High Performance” by Deborah Hartmann Preuss. It was a great talk on changing mental role models – as a member of a team, but even more important: as a manager. Because that’s the topic I’ve been obsessed with for nearly one year, it was very valuable for me to hear from her insights, compare, adapt and question her points. To be honest: There is just one I question (and I needed some hours to think about it): I’m not very happy with the term “egoless team”. I know, many trainers make use of it. Maybe I’m too sceptic because of my personal spiritual background. Every time someone starts talking about “egolessness”, I become very carefully: In most cases this is the beginning of deliberation, of suppressing individualism. It doesn’t have to be used this way in Agile, but I know that talking about “egoless …” can be a mighty weapon.
Back to the point I agree with: The key thing is that the term “Agile Manager” is an oxymoron. But what is needed instead is an “Agile Leader”.
A leader as a
- Meaning Maker
- Catalyst for Growth
- Model of Integrity
- Cultural Change Agent
- Facilitator
Deborah Hartmann Preuss explained in detail how she understands each of these roles.
I could mention many details of this talk, but I’ll pick out just two more points: The meaning of retrospectives. “If you wanna do just one agile practise, choose retrospectives.”, she said. Why? Because this is the most important opportunity to step back and reflect as a team. To remind Albert Einstein: A problem cannot be solved on the same level where it has been caused. Stepping back means changing the perspective, the level. Same thing for leaders. Integrating a retrospective in the working routine of the team extends work from single loop to double loop. Single loop work means working on efficiency (doing things right). Double loop work means working on effectivity (doing the right things), because you reflect on your work and learn more. But a decision for effectivity on costs of efficiency has to be made as a top level management decision. Once again, an act which needs a step back and some reflection.

Furthermore, I had other very good talks today: “TDD with iPhone OS” by Tammo Freese and “Science Scrum: Agile Project Management in Science” by Michael Podvinec and Joseph Pelrine.
In addition to that, a very entertaining final of “TDD with the Stars” and Alistair Cockburn’s Keynote on Hard-Agile (subtitled with “Agile is for wimps!”…).

I hope I’ll find some time tomorrow to write more about these sessions. Now it’s time to close my eyes (and hopefully not to dream of Agile Jeopardy: “Was sind Haftnotizen?”)

Powered by ScribeFire.

Many thought leaders in the agile community have started talking more about software katas – a way of practicing specific exercises until one has them memorized. Over the past several weeks, there has been an increase in blog posts and sites devoted to katas. Robert Martin has gone as far as calling them “performance art”. Should you add katas to your software toolkit?

Read full story : http://www.infoq.com/news/2009/11/code-kata-video

Esta disponible el libro de texto para el área de gestión de proyecto en la plataforma de conocimento abierto de Scrum Manager. Ofrece en la segunda parte un conocimiento general y completo de las prácticas ágiles de Scrum para la gestión de proyectos, después de haberles dado un marco de situación la primera parte del libro para ayuda a comprender la razón, fortalezas, debilidades e idoneidad de la gestión clásica y la gestión ágil,  y establecer el contrapunto de ésta última con las prácticas, modelos y gestión de proyectos tradicional.

Se puede descargar  gratuitamente, o colaborar con su compra en el desarrollo de la plataforma Open Knowledge Scrum Manager.

Descargar:
http://www.scrummanager.net/files/sm_proyecto.pdf

Original:
http://www.navegapolis.net/content/view/937/61/

Via:
http://www.bizzit.es/blog/?p=2828

As I continue to move in the Boston software development / high tech job market and talk to more and more people in the area, I not only come across the term “Scrum” in many job descriptions, but it is a word that is frequently bandied about by both recruiters and hiring managers. It is clear that there is alot of confusion in the Boston area about what “Scrum” really is, and how it relates to Agile.

There is no substitute for the experience of running Scrum daily for years, as I have done. My heartfelt advice to anyone looking to adopt Scrum in their organization is to be flexible, take it easy on the cutsey names, and keep the daily meetings very brief. If you are the “ScrumMaster”, stay organized and lead the conversation around the room, notating all limiting factors, as that becomes your to-do list. Drop me a line with your own insights or comments on Scrum!

Scrum, as some people already know, is a project managemnt methodology named after a contentious point in a rugby match. The Scrum project management method enables self-organizing teams by encouraging verbal communication across all team members and project stakeholders. At its foundation, Scrum’s primary principle is that traditional problem definition solution approaches do not always work, and that a formalized discovery process is sometimes needed.

Scrum’s major project artifact is a dynamic list of prioritized work to be done. Completion of a largely fixed set of backlogged items occurs in a series of short (many of 30 days duration) iterations, or “sprints”.

Every day a brief meeting or “Scrum” is held in which project progress is explained, upcoming work is described, and impediments are raised. A brief planning session occurs at the start of each sprint to define the backlog items to be completed. A brief postmortem or heartbeat retrospective occurs at the end of each sprint.

A “ScrumMaster” (my advice is to never call yourself this in actual human life in an office of programmers and IT personnel…but know the job well and do it well nevertheless if you are the individual who finds themselves in this role) removes obstacles or impediments to each sprint. The ScrumMaster is not the leader of the team, as they are self-organizing, but rather acts as a productivity buffer between the team and any destabilizing influences.

What happens when you start accelerating deploying?

You might says it’s not going to happen in your industry. I tell you that someone else will start showing your customer that it can be done faster and so you will have to, if you want to survive.

In any way, have a look at this precious presentation from Kent Beck: SW G Forces

PierG

One of the (many) success factors for a software team is developing a good rhythm.  Of course I’m not talking about the latest tune on your iPod, I’m talking about the pulse represented by the activities of your development team.

There are always many activities going on in a software project, the idea is to develop a pattern that helps establish the pace and predictability of the team.  Agile processes like scrum excel at this, but I like to see the rhythm played out in both micro- and macro-patterns.

Scrum establishes the overall process rhythm, demonstrated by the duration of the sprint.  More frequent activities within each sprint – like daily stand-up meetings and sprint review sessions – help emphasize the rhythm.

In my view, this is just a start.  Having a clear rhythm gets everyone’s expectations in alignment and establishes predictability.  While milestones are important, I don’t think they establish rhythm.

As an example, on a large project I managed we had the following layers of patterns at work:

The outermost pattern was the product release.  With waterfall models often this is the only marker that teams have to work with — not good!

Within the release cycle we had a specific number of “beta” releases planned.  For each we established a goal in terms of product capabilities and the level of quality.  Each beta had a specific target audience and raison d’existence.  For example, the first “beta” contained just the core features necessary to “tell the story” and the audience was an internal review team.

Of course within each “beta” cycle were a number of scrum sprints.  Because of the size of the team, the complexity of the technology and other factors the teams were using three week sprints.  Three weeks is longer than what I like to see, but this was the balance point that seemed to work best.

Within each sprint we had weekly formal releases to Q/A.  These releases had formal release notes that indicated bugs fixed and features that were ready for testing.

Because of the complexity of the system we had nightly formal full builds which were delivered to Q/A every morning.  These were deployed and “smoke tested”.  The smoke test touched each major function of the system to verify that it fundamentally appeared to work.  The test was performed manually and took about 30 minutes to carry out if everything went smoothly.  If the smoke test failed then the Top Priority for Engineering was to localize and fix the problem.  The smoke test had to pass every day, period.

Each check-in also triggered an incremental build and unit test run to catch errors.

Visually the rhythm could be depicted as shown below (this graphic is a little stiff, sorry).  It provided a set of clear expectations to the team and set a repeatable pace to a predictable release.  Like software processes, there is no “one size fits all” rhythm.  Any software engineering process has to take into account factors like the maturity of the team, their domain knowledge and the clarity around the end goals.

My My.Fragility framework adds my insights for fixed price (-negotiable scope) projects to XP and Scrum.

I included a Product Backlog Estimation model to calculate a total price using my Definition Of Agile Planning. And on top of User Stories and Story Points the Sizing of User Stories is to be considered:

The right size of a User Story is 0,5-5 ideal days (di) (ideal time = Story Points). For development. To be invEST. To comfortably fit a Sprint.

• Epic Stories can be 5-15 di. A size not suited for development but acceptable for estimating. To be split into User Stories.
• Cosmic Stories are >15 di. They can serve only as a beginning to understand a Product, not for estimation or development.
• Tiny Stories are < 0,5 di. To be combined into User Stories.

Note: ‘Minimal Marketable Features’ (MMF) from Kanban can be a set of User Stories. Possibly an Epic Story.

The best base to estimate is experience. When experience is limited, use relative estimates (complexity scaling). I use a 1-2-5 scale:

• Size is set upon complexity to 1-2-5-10-20-50-100-… Always use the higher value if you end up in between two points.
• Find some reference points in your experience to compare.
• Refine until you end up with real estimates (Story Points).

note: Ideal time is development time without breaks, questions, problems or any interrupts. It is multiplied with Velocity to get Planning days.

Este post ya lo tenía cocinándose desde hace un tiempo pero aunque por lo general no puedo realizar un trabajo de edición perfecto siempre trato de hacerlo buscando la imagen, las citas bíblicas y leyéndolo para ver si he expuesto lo más clara posible la idea; por esa razón no lo había puesto. Jorge un Lector de Guatemala me preguntaba cuando volvería a poner post de planificación, pues Jorge, aquí iniciamos de nuevo con este post esa faceta del blog que hacía falta.

Ya habíamos hablado en la primera parte acerca de lo que era y lo que significaba scrum, en esta ocasión vamos a empezar a explicar sus componentes para que podamos aplicarlo a la gestión de nuestros proyectos.

Vamos a empezar a entrar entonces en materia definiendo a los actores de la obra ya que es importante estar organizados y saber que deben de hacer cada uno de los jugadores:

Proverbios 15:22
(22)  Los planes fracasan por falta de acuerdo,  cuando hay consejeros, se cumplen.

Scrum se divide en 5 grupos de personas que listo a continuación:

-          Product Owner

-          Scrum Master

-          Scrum Team

-          StackHolder

-          Users

Product Owner
(Propietario del producto) Este señor es el que dice que va a hacerse en cada sprint o que desea obtener, para poder mostrárselo a los interesados, el product owner debe de conocer muy bien y saber que se requiere del producto, ya que él será el que al final diga hoy haremos pantallas de ingreso o realizaremos web services, etc. Es fundamental su conocimiento de lo que se desea obtener para el éxito del proyecto.

Scrum Master
El asegura el seguimiento de la metodología y el cumplimiento de las metas trazadas, dirige las Scrum Meetings y se encarga de lidiar con las presiones externas del proyecto. En pocas palabras es el director del proyecto.

Interactua con el produc owner ya que este es el que le dice que desea ver en ese sprint y él se encarga que el equipo lo realice.

Scrum Team
Ellos son los que se encargan de desarrollar las funcionalidades que el product owner haya elegida para este sprint. Son los desarrolladores pues!!!

StackHolder
“Los interesados”, estos son los que financian el proyecto y los promotores de dicho proyecto; las gerencias interesadas en tener una nueva herramienta o software el presidente de la empresa que considera que con esto incrementara ventas etc.

A ellos el product owner le mostrara al final de cada sprint que se está haciendo y ellos decidirán si se continuo o se detiene el proyecto. El Scrum Master tiene que lidiar con estos para justificar el desarrollo que se está haciendo y para evitar que el proyecto se descarrile en el camino por interferencia de ellos o falta de paciencia.

Users
Al final pero no menos importantes los usuarios, ellos lógicamente prueban la aplicación y ven si cumple sus expectativas, aportan ideas o necesidades no consideradas.

Bueno estos son los jugadores pero si ustedes se percatan he hablado de sprints y scrum meetings, pero esto lo voy a tocar en otra entrega para que comprendan como funciona esta metodología por el momento nos quedamos aquí.

Que Dios les guie siempre, con pasos firmes hacia sus metas y objetivos.

Sabiduría 3:11
(11)  Desdichado el que desprecia la sabiduría y la educación; vana es su esperanza, baldíos sus esfuerzos, e inútiles sus obras.

Nota: Para este post usamos la biblia de Jerusalén para obtener las citas

It’s quite a long time, i haven’t shared anything over my blog. after thinking a while, i decided to share about our maintenance sprint.

since we have been (tekSymmetry) moving from traditional project management to agile project management. as usual we are struggling and learning through our faults and adjusting, adapting and correcting accordingly to accommodate agile in our family.

agile project management seems very simple in theory and easy to transform but in reality it has so many mental and understanding related conflicts which we are stucking and discovering. yes we should have followed this and that.

for those who just started and don’t like to get in argument. you just start with scrum first, & follow all prescribed processes (learn through adapting approach.)

after working on our project for last 7 months and completing more than 20 full and short (in our case, full = 2 weeks, short = 1 week) length sprints. we reached to a point where we are feeling much confident with our process adaptation. here i will demonstrate how we are managing our maintenance sprint.  definitely our way of managing sprint won’t be the best solution for every contexts.

what is maintenance sprint?

before i proceed, i should explain what is meant by maintenance sprint.

here in the picture, you could notice few greenish circles, which we call maintenance sprint. maintenance sprints are planned for supporting a release with related bug fixing. as you know most of the software releases don’t come up with 100% bug free, it comes up with lot of known and unknown issues. to protect our visitors we keep maintenance sprints to provide continuous updates and hot fixes (;)).

how are we doing the maintenance sprint ?

Usually we are doing the following tasks during a maintenance sprint -

• Product owner prioritize the issues and provides us the list
• Sprint planning meeting with client
  
• Team select implementable issues
  
• Product owner can reshuffle and prioritize issues before sprint kick starts
• After everyone agrees (team and product owner) team tags all issues (in issue tracker) with the target release version (ie. 0.12.2)
  
• Daily team stand up meeting
  
• Team provides feedback on client’s reported issues during the day time.
• Daily reporting (we call it end of the day report)

So, how are we utilizing the white board ?

well, first let me show you our white board -

Global TODOs:

During the sprint day, this portion of the board is synchronized and maintained. we usually enlist the following topics -

• Major issue
• Task which requires feedback
• Impediment
• Any events which requires our (team) attention
• Any collaboration requirement (ie. need feedback ASAP on issue #2034)
• Any issue which we need to remember. (ie. Send report, deploy before leave the office)
• When tester finds problem during testing, they write it down on the board with red pen
• Every day during stand up meeting we write down all events/tasks/todos on the board.
  

Status BOARD:

This portion of the board is similar to scrum task board, instead of putting sticky paper we use marker to write down the issue number.

when we make progress we move issue from WIP (work in progress) to WFF (waiting for feedback) or WFT (Waiting for test). later our tester moves them to DONE. actually, rather moving physical sticky paper we wipe out the previously written text and write it again on the new column.

this board is maintained through the whole day. whenever we take new task we add it on WIP and when our task is completed, we move it on Waiting for test queue.

we follow the following rules -

• per person only one WIP (work in progress) item can be selected. (taken from kanban)
• whenever we make progress it will be reflecting the board (developer wipe out from WIP and move to next status)
• tester keeps his eyes on “test” column of the board, they eagerly wait for the change on this column
• if tester finds some problem with the issue, the write it down on “global todos” portion of the board in red pen.
• developer can retake any issue (if tester reported not resolved over “global todos”)
• during stand up meeting development team can discuss which issues need to be resolved first.

Daily report:

At the end of the sprint day, we generate a report from the board and send them to every stakeholders, clients  & management. we keep this report very simple we add the 3 parts in the daily reporting -

• what we have resolved
• what we working on
• what we have tested

all of these resolved issues are deployed in test server so our client can review them.

we found this is very collaborative and simple. more over it has less overhead to manage. it is so visual that daily (end of the day) reporting is not restricted to any specific person. anyone can do it.

best wishes,

Reposted on my company blog

BizTalk Custom Pipeline Components

Business Case:

A Sweden based ICT Company were facing a problem in archiving of invoice message (TIFF files). They had to do many manual processes for the archiving which required automation.

Requirement:

The requirement of the client was to create a custom pipeline component in BizTalk to support archiving of invoice message (TIFF files). The proposed solution has to interact over secure FTP (SFTP). The invoices have to be transferred to the second party and acknowledgement of the receipt is to be recorded. If there is any error in the process then it has to be notified by email. A strict requirement was that the invoice and accompanying files should be transferred as a single set. If there is any error then the sending of invoice should be cancelled and notified by email.

Decos Solution:

BizTalk Pipelines allow you to customize the processing of XML documents received or sent via the various BizTalk adapters. Custom Pipeline components extend the behavior of Pipelines to include processing data of virtually any format. They can be a powerful solution if you support legacy systems that require integration with other products, but your legacy data format does not follow standards. It may contain carriage returns in odd places or records spanning any number of lines of text, for example. The only stipulation is that the data emerging from the Custom Pipeline must be some form of XML document.

The client’s requirement was to build custom pipeline component in BizTalk to support archiving of invoice message. The invoices which were TIFF files were generated at the client’s side. First step taken by Decos Team was creation of windows services to interact with SFTP server at source and destination sides. And then the Enhancements to third-party nSoftware component were done to search/create directories recursively. To complete a Pipeline, one or more Pipeline components from within Visual Studio .NET were needed to be selected and then they can be added to the Pipeline. None of the existing BizTalk Pipeline components satisfied the client requirements, so Decos had to build a custom pipeline component. A custom pipeline component for archiving the invoices was created. After creating the custom Pipeline component, the pipeline was deployed to the C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components directory so the custom Pipeline component can be added to the Pipeline in the BizTalk 2006 project. After deploying the custom Pipeline component, the component was added to the Pipeline component toolbar. The logic in BizTalk Orchestrations was implemented to ensure that files are received as a single set and error conditions are detected and notified. Technologies being used for this solution: BizTalk Server 2006 R2, nSoftware SFTP adapter, SSH library

The Result:

Decos team delivered this solution in 20 days and is currently working on the development of additional features. Client was delighted to have an advanced solution based on Biztalk Server 2006 to get relief from their pain area of archiving the invoice messages.

GET A FREE QUOTE

more: www.decos.in

]]> http://zenagile.wordpress.com/2009/11/24/what-is-a-business-analysts-role-in-an-agile-world/ Mon, 23 Nov 2009 23:27:03 +0000 magia3e http://zenagile.wordpress.com/2009/11/24/what-is-a-business-analysts-role-in-an-agile-world/

The last ABAA meeting for the year is nearly upon us — 8 Dec 2009. The topic of conversation will be ‘what is a business analyst’s role in an agile world’?

At first I thought this would be a very interesting conversation but the more I thought about it the more I thought it was a little naive to be asking the question in this way. Is there an actual role? … see for yourself . . .

Kanban

• Prescribes no formal roles

ZenAgile

• Samurai – the defender of the project
• Roshi – the project lead, teacher and mentor
• Sensei – the team’s mentor, leader and users’ champion
• Team – multi-disciplinary where its members are chosen based on need

Scrum

• Scrum Master – protector and champion of the team from The Powers That Be
• Product Owner – customer representative and stack prioritiser
• Team – multi-disciplinary based on need

Extreme Programming (XP)

• Tracker - measures and communicates the team’s progress
• Coach – like the Sensei in ZenAgile this is a supporting role that helps a team stay on process and help the team learn
• Tester – helps the customer define and write acceptance tests for user stories in the same way a Product Owner might do in Scrum
• Customer - defines what is the right product to build, determines the order in which features will be built, and makes sure the product actually work
• Programmer - implements the code to support the user stories
• Programmer administrator - manages the programmer environment

DSDM [1]

• Executive Sponsor – commits appropriate funds and resources
• Visionary – initialises the project by ensuring that essential requirements are found early on. The Visionary has the most accurate perception of the business objectives of the system and the project. Another task is to supervise and keep the development process in the right track.
• Ambassador User – the knowledge of user community into the project, ensures that the developers receive enough amount of user’s feedback during the development process.
• Advisor User – the one who represents important users’ viewpoints
• Project Manager – manages the project in general
• Technical Coordinator – designs the system architecture and controls the technical quality in the project
• Team Leader – ensures that the team works effectively as a whole.
• Developer – interprets the system requirements and model it including developing the deliverable code and build the prototypes
• Tester - checks the correctness in a technical extents by performing some testings. Tester will have to give some comments and documentation.
• Scribe – gathers and records the requirements, agreements, and decisions made in every workshop
• Facilitator – manages the workshops progress, acts as a motor for preparation and communication.

RUP

• Well, it has over 30 roles … so let’s not go there

If the essence of agile is simplicity then there’s certainly something wrong with some of these ways of working. The most striking thing in all of these is the lack of an actual, dedicated, business analysis role. There are certainly elements of a standard BA in DSDM’s Scribe and Facilitator roles. The Tester and Tracker roles in XP could also be done by someone with a BA background. Craig Brown of Better Projects has even suggested that a BA could undertake the role of the Product Owner in Scrum. But Scrum, ZenAgile and Kanban essentially take the most appropriate people with the most appropriate skills in order to acomplish a specific task or activity. In these, there is obvious room for a BA role to lead or follow, but no defined role for a BA to play as it’s task dependent.

So what is a business analyst’s role in an agile world? Just like there is no PM role in agile there is also no actual BA role either. In some areas that focus more on software engineering there aren’t even any standard analyst roles but moreover a focus on eliciting customer needs directly. It means that in some agile projects there may not be a perceived need to involve an analyst at all.

In reality, though, someone needs to assist with the following:

• Understanding users’ needs, wants, expectations, capabilities and attitudes
• Communicating and documenting those needs
• Translating those needs to those who will implement the project
• Ensuring that the output meets the needs of users and the strategic goals of the project and, moreover, the organisation as a whole

This reinforces that skills in business analysis are important for everyone in the project and not just a single role as is prevalent in traditional waterfall projects. It suggests that everyone, from the project lead, samurai or scrum master, should have these skills.

So what is a business analyst’s role in an agile world? There is no BA role. But everyone should definitely have a business analysts skills.

M

- – - -

1. http://www.businesspme.com/uk/articles/rh/49/Roles-of-DSDM.html

Last Wednesday’s STC meeting got me thinking about my writing style again.  While I’m always writing, it’s not a linear progression from spec to outline to topics to completed project. 

Until I started working in an Agile environment, my progress on a project went something like this:

1. Read the design specifications and functional specifications.  Try to get an idea of what features were being built.  If I was very lucky, the specs would include a use case, describing what the customer wanted the software to do.
2. Count up the number of new applications, tabs, subtabs, actions, dialog boxes, buttons, etc.  This is usually the point when I could start estimating doc effort, as each feature and/or task will usually result in at least one new topic, with a small fudge factor added to cover additional concept or reference topics that might be required.
3. Generate an outline based off the projected UI features.  Each tab or subtab generally gets a concept topic.  Each action, button, or dialog box usually gets at least one task topic, and sometimes two (as in “creating a widget” and “deleting a widget”).  Estimate the number of concept tasks for toolbars, types of widgets, possible widget statuses, commands, etc.
4. Start writing procedures.  Open this, select that, enter something, click save.  If I’ve got a well written spec I can often start on a draft before the software is even coded.  Sometimes you can write a complete draft of procedure before the software is even stable.  But it’s more likely that I’ll end up writing a partial procedure with the first several steps of a draft procedure then write myself a note that “Click X and what happens next? Software crashes as of Build# on Date ##/##/##.” 
5. Next I generally add reference material.  Depending on the software, it might be documenting toolbar buttons, icons, commands, possible statuses, etc.
6. The last thing that I usually write are the concept topics: overviews of new features, descriptions of new tabs, subtabs, screens, best practices.  It usually takes a while to really “grok” the software and how customers will use it.

When we first made the switch to Agile in January 2009, my manager wanted to manage me like the rest of the development team.  The developers had user stories, I had documentation stories.   The developers generated a list of tasks and then estimated story points for their stories.  I generated a list of tasks and topics and attempted to estimate my doc stories.  The developers kept a burn down chart, and I did the same. 

The only problem was, writing documentation is not like writing code and I don’t have a linear writing process.  I don’t tend to start on a topic, write it, and move on to the next topic.  I tend to work on multiple topics at once, writing as much as I can on one topic before moving on to the next.  Sometimes I’ll have an insight in the car during my commute and will need to capture that before I forget it.  I keep notebooks in my car and in my purse so I can scribble notes to myself. 

My manager expected me to work like a developer.  To pick one task and work on it until it was completed.  But I couldn’t write the doc until there was completed code.  And the first four sprints we didn’t have completed code until the last day or two of the sprint.  So if I can’t write until the last couple of days of the sprint, what am I supposed to do for the first three weeks?  (I spent my time closing doc bugs, many of which had been open since before I was hired.)

I wonder how I’m supposed to adjust my writing process to fit into Agile. I’m a multitasker.  I usually work with multiple files open at once.  My brain tends to makes connections between what I’m doing and something that I will be doing in the future, or something that I wrote in the past.  I’m a list maker.  I’m frequently opening up files and making notes of questions, resources, further research to follow up on later.  Part of this is by necessity.  Writers almost never have the luxury of only working on one project at a time.  Especially lone writers.  Right now I’m writing an Installation Guide, working on fixing doc bugs for the next patch release, writing and estimating doc stories for the past several sprints of development.  And my work is dependent on having functional code.  If I try to work through a procedure and the feature isn’t complete yet, I’ll put the procedure aside and work on something else. 

At Wednesday’s STC meeting the two writers said that they document one sprint behind their Agile development teams.  Both of the writers have been doing Agile for three years.  Before we both got laid off, my manager and I had agreed that this was the approach we were going to try.  Now that I’m only working two days a week, I don’t really have a choice but to write the doc after the developers have finished a sprint.

And yet, at the Nashua Scrum Club meeting on Thursday, someone said that if you’re doing testing or writing documentation a sprint behind development that “You’re not doing Agile.”

So, am I doing Agile documentation?  This is a question that I have yet to answer.

Sneaking up on it

I think I was destined to become an Agile technical writer.  In the summer of 2008 I was working for a small software company that produced two different products.  After finishing up a stretch of concentrating on the documentation for product A, I checked in with the product B developers in New Zealand.  I discovered that they’d decided to adopt Agile development without telling me. 

I responded the way I always do when faced with a new idea.  I did some research.

I started out by checked the Techwr-l archives for threads that mentioned Agile.  I’ve been a member of Techwr-l since 2005, and since I use G-mail to manage my list subscriptions, it was fairly easy to find the few discussions of Agile from the past couple of years.  Unfortunately, what little I found didn’t sound too encouraging from a tech writer’s point of view.

I also looked through my collection of back issues of the Intercom, the journal of the Society for Technical Communications.  I found two articles about Agile documentation:

• Adapting to SCRUM: Challenges and Strategies (July/August 2007)
• Extreme Documentation (February 2003)

Wikipedia and Google turned up plenty of articles, and also led me to the Agile Manifesto and Scott Ambler’s Web Site.   I had to do quite a bit of reading before I finally realized that when Agile proponents were writing things like “Documentation should be just barely good enough.” and “The benefit of having documentation must be greater than the cost of creating and maintaining it.” They were talking about project documentation (design documents, functional specs, etc), not product documentation like User Guides and Help. And with the exception of the STC articles, none of the resources I was reading were talking about what a technical writer would produce, or how they fit into Agile (other than being part of the Scrum team).

I had just started reading Agile Software Development with Scrum when a friend forwarded a job opening to me.  The job description sounded like a very good fit with my skills and interests.  The company was looking for someone with experience working in an Agile software development environment.

By this point I’d learned enough about Agile to know that the way we were implementing it at my company (developers in two different cities, the tech writer and project manager on a completely different continent) was not going to be conducive to my success as an Agile Technical Writer.   And I was intrigued by Agile. I now knew enough to be able to “talk the talk” during my interviews.  During my interview I quizzed the VP of Engineering.  They were still using the Waterfall Model, but were planning to switch to Agile development at the beginning of 2009.  

I liked the idea of getting in at the beginning and being able to shape the way the technical writer fit into the Agile team.   They made me an offer, I accepted, and I started work there in October 2008.

Fast forward to May 2009 and the end of Sprint 4.  The last day of the sprint our company had a layoff, and I was one of the casualties.  Six weeks later they called me back to work part time (two days a week).  So while I’m still working in an Agile environment, I’m no longer embedded with the team working to document the current sprint.  Hopefully that will change as the economy starts to recover.

Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.

After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?

• The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
• The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
• Our stories were obviously poorly broken down.
• We were not representing the work that was actually getting done properly on our Scrum board.
• The knowledge gained from earlier spikes may not have been leveraged to their full potential.
• We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.

Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.

• For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
• During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
• Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
• If we find ourselves doing something that is not represented on the Scrum board,
  1. ask yourself if you should even be doing it.
  2. if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
• Continue with one week Sprints.

So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on.  During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not.  As a whole we re-focused on areas that we had gotten too comfortable with and neglected.

It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.

By Hemant J. Naidu

Post excelente escrito pelo André Faria Gomes. Muito bom mesmo! Podcasts sem dúvida são um dos meios mais indicados para adquirir conhecimento em tecnologia, ainda mais quando você está antenado no que Martin Fowler, Kent Beck, Rod Johnson entre outros estão falando. Retirado do andrefaria.com.

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo – Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

I have combined personal insights for fixed price (-negotiable scope) projects with practices from eXtreme Programming and Scrum in my My.Fragility framework.

The main estimation steps from the framework’s Product Backlog Estimation model were highlighted in my Definition Of Agile Planning. But the model also implies at least an understanding of some definitions.

After my definition for User Stories here’s how I use Story Points:

• Story Points equal ideal time (“ti”). But using ‘Story Points’ might prevent people from confusing it with realistic time. The eXtreme Programming notion of Gummy Bears (“Bg”) might be a bit too abstract, although it’s fun to use.
• Ideal time is the development time for a User Story without breaks, questions, problems or interrupts of whatever nature. Spending every minute of every working day on productive coding.
• Ideal time is mulitplied with Velocity (“v”) to estimate Planning time (“tp”). In my experience, an overall velocity of 2,5-3 results in a realistic number of planning days.

planning time (“tp”) = ideal time (“ti”) * Velocity (“v”)

• An alternative definition of Story Points is the number of productive coding hours per day. This is generally accepted as maximum 5-6. Velocity is then expected to be around 1,33.

Note I generally apply an overall Velocity to all User Stories, although my model allows a specific Velocity per User Story, e.g. depending on the expected complexity.