Skip to content

Feed aggregator

How to Start to Solve the Problems of Your Product Development Organization

Leading Agile - Mike Cottmeyer - Thu, 04/30/2015 - 19:01

I have been thinking a bit about organizations and in particular, where I need to engage organizations to be most effective at helping them solve the problems of the overall business.

To better understand what has shaped my thinking I’d like to start with a bit of history around my background and life experiences. I initially started as a networking administrator within an old school ISP service organization and then my career progressed away from support services and into shared services and eventually product development. My experience in a variety of roles provided me with a set of perspectives around service and product development organizations.

These two key organizational types have distinctly different engagement models for me. If you have read some of my other work, I have a solid perspective on solving problems, and you’ll know that I don’t implement agile to be “more agile”. Agile is a large tool in my toolbox and tends to assist in solving a core set of issues that affects organizations: time to market, predictability, cost reductions, and quality to name a few. When I enter organizations, these two organization types are patterns that I look to identify to help me solve their problems.

The Service Organization

A service organization is generally an enabler of a real business function like sales of human capital or, put in a nicer way, staffing. Thinking back to my history with a big player in the healthcare staffing space, IT was a function of the business not the business itself. We typically did things like CRM development and website development that facilitated lead generation and the like. The business makes a pull for a new service to be available to the real product Sales. In this type of organization, I find it useful to transform in IT unless I am encapsulating the entire value chain from initial contact to opportunities for converting and through to conversion of the sale and possibly beyond.

For that reason, the IT group is there to make the life of the sales organization more efficient, or restated, to enable more and higher sales and generate more money. IT is an enabler for sales. In these organizations, I am fine with an IT implementation of agile that gives lead times to the organizations and that can make reliable commitments to delivery. The overall goal is to enable generation of more leads and to close more sales buy providing services that enable the organization.  The goal would be to reduce cycle time through automation of processes.

The IT failure would be if they are the bottleneck in the cycle time or if they are elongating it.  Beginning with IT allows me to focus on a predictable delivery of capabilities to an organization with the goal of enabling the real customer of IT, sales. Sales in this case would be to both the businesses wanting a staff augmentation and the person that wants a job. They are split out in organizations depending on the size of the staffing company, but those are the two basic products.

Us versus Them

The Product Development Organization

I find product development organizations to be a little bit different and I’ll warn you, I don’t share the same sentiment others do. Product development organizations are fundamentally broken most of the time. I hear “the business” a lot… and in truth, I hear it in service organizations too. Nevertheless, “Us and them” is the prevailing attitude in sales, marketing, product, and IT in many organizations. In my experience, product and development are one and the same most of the time if you use the 80/20 rule. They share the same agenda. Get products to market that improves the bottom line while excelling in the market.

Sales heavy organizations will tend to favor contract fulfillment, market penetration, and customer retention.

Market based organizations will tend to favor consumer behaviors, finding new markets, and trends.

Either way, you develop product to help you fulfill those needs. In both cases, I foster or create the partnership between product and IT organizations. That’s one reason why I look to solve the problems of the CEO or VP of a division. The person sponsoring the change needs to be a part of the organization that can ensure the bond does not break.

The post How to Start to Solve the Problems of Your Product Development Organization appeared first on LeadingAgile.

Categories: Blogs

Agile Development Conference, Las Vegas, USA, June 7-12 2015

Scrum Expert - Thu, 04/30/2015 - 14:45
The Agile Development Conference West is an event focused on agile methods, technologies, tools, and leadership principles from thought leaders that takes place in Las Vegas. You will find at this conference inspiring keynotes, in-depth tutorials and a wide range of conference sessions. In the agenda of the Agile Development West Conference you can find topics like “An Introduction to SAFe: The Scaled Agile Framework”, “Measurement and Metrics for Test Managers”, “Build Product Backlogs with Test-Driven Thinking”, “Specification by Example: Mastering Agile Testing”, “Six Free Ideas to Improve Agile Success”, “Great ...
Categories: Communities

Scrum Days Poland, Warsaw, Poland, May 28-29 2015

Scrum Expert - Thu, 04/30/2015 - 14:39
Scrum Days Poland is a two-day conference focused on Scrum and Agile project management approaches. It aims to create an environment where people can meet, build social networks, do business and have fun with a new conference experience. In the agenda of Scrum Days Poland you can find topics like ” Team Coaching Through Groupthink”, “Self-organization applied”, “Implementation of Personal System Interaction Theory in Every Day Scrum Work”, “Daily Need For Speed – Can You Truly Read Your Scrum Speedometer?”, “The Lucifer Effect: How to Turn Good People Into Bad Teams”, ...
Categories: Communities

What DONE Looks Like in DevOps

Agile Management Blog - VersionOne - Thu, 04/30/2015 - 14:29

shutterstock_107535005Have you ever wondered about the meaning of DONE in DevOps? If you’re including DevOps in the definition of DONE, what are the agile changes that need to occur? Tweet This.

Fortunately, after working with many organizations exploring these questions, I’ve figured out that the answer isn’t that difficult.

So, what’s the meaning of DONE in a DevOps world?

Definition of Done in a DevOps World

DevOps creates the need for a lot of changes in the development process, not just from the technical aspect of continuous delivery, etc., but also with regards to agile. One of the aspects of agile that’s most interesting is the definition of DONE in a DevOps environment.

This isn’t a new problem by any means; people have been arguing about what the definition of DONE should be since Scrum became popular, and maybe even prior. As development teams begin to infuse DevOps practices, they need to rethink the definition of DONE. In the DevOps world, DONE doesn’t just mean it is coded and tested; it means it will work in production.

A few years back, at one of VersionOne’s AgilePalooza events, a tester asked a question that saddened me. She asked, “So what do you do when the story is done, but it hasn’t been tested?” I think a tear rolled down the cheek of each of the panelists as we had to explain, “it’s not done, if it hasn’t been tested.”

Fast forward a few years, and now we are in a world where most people recognize if code hasn’t been tested or the story is not done and stories are still missing the hooks for monitoring tools. There may be no way of saying, “It is not done until we know that it can be deployed safely and we can monitor its health while it is in deployment.”

In advocating change, I am suggesting the addition of DevOps requirements to your definition of DONE. I’m asking for you to agree that no story is done until the code has been written. And if you aren’t pair programming, then the peer review has happened, the tests are all passing, and the hooks for monitoring, performance evaluation and health checks are in as well. This is vital if you want to be successful with DevOps.

DevOps is all about moving quickly and deploying continuously. If you’re going to deploy continuously, you need to know that what you’re putting out is ready to go out. That means you have to be prepared for when the code meets the real world. You need to know right away if something bad happens when the code is deployed. You can’t wait until somebody calls and asks, “Why can’t I get onto your website anymore?” That is not good enough. If you deploy something, you have to find out before the customer does if something is not working right.

You have to make a few additions to stories to incorporate DevOps into the definition of DONE. The first step is adding the requirements to enable you to understand how the code is doing after deployment. Second, when you are planning a story, you’re going to need to estimate based on what it means to have the code in a state that will be successful post-deployment. Third, every single member of the team is a developer, and every single member of the team is a tester. Every single member of the team is now on the operations staff as well. That is where true success will happen in the DevOps world.

Conclusion

If you’re not fusing DevOps into your agile stories, you should start doing so right away. If you already are, make sure you’re including the hooks for monitoring, performance evaluation, and health checks as well.

What do you think about including DevOps into the definition of DONE? Are you going to start including post-deployment requirements in your definition of DONE?

 

versionone-coaches-steve-ropaSteve Ropa
SAFe Agilist, CSM, CSPO, Innovation Games Facilitator
Agile Coach and Product Consultant, VersionOne

Steve has more than 21 years of experience in software development and 12 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Categories: Companies

Deliberate Practice: Building confidence vs practicing

Mark Needham - Thu, 04/30/2015 - 09:48

A few weeks ago I wrote about the learning to cycle dependency graph which described some of the skills required to become proficient at riding a bike.

IMG 20150430 073120


While we’ve been practicing various skills/sub skills I’ve often found myself saying the following:

if it’s not hard you’re not practicing

me, April 2015


i.e. you should find the skill you’re currently practicing difficult otherwise you’re not stretching yourself and therefore aren’t getting better.

For example, in cycling you could be very comfortable riding with both hands on the handle bars and find using one hand a struggle. However, if you don’t practice that you won’t be able to indicate and turn corners.

This ties in with all my reading about deliberate practice which suggests that the type of exercises you do while deliberately practicing aren’t intended to be fun and are meant to expose your lack of knowledge.

In an ideal world we would spend all our time practicing these challenging skills but in reality there’s some part of us that wants to feel that we’re actually improving by spending some of the time doing things that we’re good at. Doing things you’re not good at is a bit of a slog as well so we might find that we have less motivation for this type of thing.

We therefore need to find a balance between doing challenging exercises and having fun building something or writing code that we already know how to do. I’ve found the best way to do this is to combine the two types of work into mini projects which contain some tasks that we’re already good at and some that require us to struggle.

For me this might involved cleaning up and importing a data set into Neo4j, which I’m comfortable with, and combining that with something else that I want to learn.

For example in the middle of last year I did some meetup analysis which involved creating a Neo4j graph of London’s NoSQL meetups and learning a bit about R, dplyr and linear regression along the way.

In January I built a How I met your mother graph and then spent a few weeks learning various algorithms for extracting topics from free text to give even more ways to explore the dataset.

Most recently I’ve been practicing exercises from Think Bayes and while it’s good practice I think I’d probably spend more time doing it if I linked it into a mini project with something I’m already comfortable with.

I’ll go off and have a think what that should be!

Categories: Blogs

Find the Other Stories

Evolving Excellence - Thu, 04/30/2015 - 08:36

By Kevin Meyer

I recently came across the following TED Talk by Chimamanda Ngozi Adichie where she talks about the "danger of a single story."  From growing up as a kid in Nigeria to studying in the United States and into adulthood, she describes how both herself and others, having only heard a single story about a certain situation, critically misunderstand the person or circumstance.

We all experience the power of the single story, often without realizing the danger.  How many of us get our news of the world, and thereby form opinions, from just a single news source?  Or even worse, from news sources that we believe already reflect our opinions, thereby denying us the need to have to think about other perspectives, resulting in an increasingly polarizing form of confirmation bias?

How many of us as leaders simply listen to the single story told to us by our staffs, or perhaps even just a computer system - both of which may be predispositioned or programmed to conform to our existing perspective?

The single story may be an incomplete picture of the situation - or even dead wrong.

This is the power of genchi genbutsu - go and see.  Go to the real place to truly understand.

My wife and I both lived overseas as kids, and experienced the danger of the single story when interacting with friends and family back home.  Perspectives and opinions were sometimes just plain wrong.  This is why we love to travel and have visited over 60 countries.  With each new place we try to learn about and understand the overlapping tapestry of stories to get a true sense of the people and place, which is almost always very different from what we expected from the single story we'd read or heard about before visiting.

In Laos, one of the few remaining hardcore communist countries, we learned about the vibrant undercurrent of capitalism that has put a TV in the middle of many Hmong grass huts - often showing western shows such as [shudder] The Real Housewives of Orange County.  In Tanzania we ventured outside the game parks that most tourists stick to to see how a group of dedicated people are fighting an incredible infant mortality problem - which was documented in a Gemba Academy video series.  In Panama last Christmas we left the relaxing beaches and spent a day at a women's shelter in the very dangerous city of Colon.  We've been to the slums of India, animal rescue organizations in Nepal, broke bread with villagers in a small hill town in Italy, witnessed the social impact of an entire generation of men murdered by the Khmer Rouge in Cambodia, and walked through the vibrant township of Soweto outside the nearly abandoned and squatter-filled inner city of Johannesburg in South Africa.  Every place has many stories.

That tapestry of multiple stories is the real picture.  Not the single story that you read about in the paper or hear about on CNN, let alone entertainment channels like Fox or The Daily Show.

As leaders we must do the same.  We can't rely on a memo from our staff or a report from an MRP system.  Those are single stories, and will invariably be an incomplete picture - or just wrong.  Just as a single story can give us a potentially dangerous misunderstanding about geopolitical events, so can it about situations within our organizations.

Go and see.  Observe, ask questions, challenge, and reflect.  Learn the many stories to understand the true situation.

Categories: Blogs

You Won’t Believe What These Five Lenses Can Show You About Your Product

Tyner Blain - Scott Sehlhorst - Thu, 04/30/2015 - 08:01

three priorities of product management - desirability, feasibility, viability

Fundamentally, product management requires you to assess, synthesize, and prioritize the needs which drive the creation of your product in the context of three main objectives: desirability, viability, and feasibility.  While laudable, these objectives are too abstract to be actionable.  That’s where the five lenses come in (I could not resist the Buzzfeed-styled title).

The Product Strategy Grid

Steven Haines wrote The Product Manager’s Desk Referenceand from (the first edition of) his book I learned about the product strategy grid.  Over the years, I may have tweaked it to serve my needs, or used it a little differently than he presents – honestly, I don’t remember – but I believe that I am staying with the spirit of what he originally described for us several years ago.

As a product manager, we build roadmaps to help communicate to the team building the product, a set of instructions / goals / themes designed to manifest the product strategy. I believe the product strategy grid is a fantastic tool for

  • Aligning your organization around a definition of the product strategy, given the company’s objectives and perspective on the future
  • Clearly articulating the expectations the leadership team has – the measures by which “success” is defined for the product
  • Establishing an accountable expectation of the outcomes which are anticipated by the product manager for a given investment (aka roadmap)
  • Communicating a shared view of the future – beyond the immediate scope of delivery – with the entire team

The other day, with a client, I made this statement: I believe the product manager is entitled to know the measures of success, when being asked to build the roadmap.

The product strategy grid is too much to cover in a single blog post – even the long ones I tend to write.  I do a multi-day workshop to define what it means for a particular team.  Conceptually, I can walk an engaged and enthusiastic team through it in two hours.  I know this because I’ve tried (and failed) to do it in one hour.

For this article, I’m only going to talk about five lenses – the key to how I build out a product strategy grid (lenses translate to rows in the grid).  There may be better ways, but this one works.  Really works.  So thank you Steven for starting me down this path.

Five Lenses

five lenses on the keys to product strategy - customers, competitors, finances, technology, operations

Some day I may feel six lenses, or four lenses, to be better than five.  When using this technique at the portfolio level, I’ve used seven lenses to understand and assess not only the per-product context, but the context of the firm and how they take a portfolio of products to the market.  But for now, there are five.

I guess I should describe what I mean by the word lens.  This is the kind of corporate jargon that creeps into conversation and eventually shows up on someone’s meeting-bingo card. In this context, I mean a lens to be something you use to view your product from a particular perspective.  Some investments we make in a product are important because of their impact on our competitive position.  Other investments are important to reducing costs or achieving revenue goals.

elephant (thank you Deror Avi)

Applying lenses to how we view our product allows us to avoid the problem of the blind men and the elephant.  As an organizational bonus, it allows different stakeholders with specific areas of responsibility and interest to both contribute to the conversation, and develop a shared understanding of a holistic perspective on  the product.

Looking AT Each Lens

I’m not trying to tackle the full breadth and power of the product strategy grid in this article.  Each lens reflects a “row” in the grid.  There’s more stuff defining columns.

Let’s take a look at each lens.  One thing you’ll notice – some lenses have arrows pointing to two objectives (the competitive environment lens points to both desirability and viability), where some point to a single objective.  This is a reflection of my attempt to align lenses with the areas of focus in an organization by which people tend to have a sense of ownership of things.

Jeff Patton talks elegantly about reaching shared understanding (in User Story Mapping) – which is absolutely an intended outcome of using these lenses to organize views of the product strategy.  I also believe a team will be more effective when there are champions who feel deep connections with what everyone should look for (and see) through each lens.

Customer Environment

The customer lens is the one you look through when you are asking “who is my customer?” and “what problem are they trying to solve?”

When we talk about markets changing, targeting specific personas, and understanding problems, this is where we view the understanding we develop.  When discussing the inclusion of a particular feature in the product, we can look through through this lens and ask questions.

  • Would this feature help one of our target personas to solve a problem they care about?
  • To what degree of completeness / goodness / done-ness should we address this problem?
Competitive Environment

When you want to know if your product is “better” than your competitors, this is the lens you look through.

Conversations around relative market position, comparing our product with competitors happen here too.  We can ask specific questions here

  • What are the relative price and value of our product and our competitors products?
  • For the most important problem in our most important market, how does our product compare?
Financial Health of the Product

Being objectively better for our customers does not necessarily mean our product is “good.”  In investing, there’s a phrase – “a good company can be a bad investment.”  There’s an analog to be found in product management.

Our focus is on our customers, but it is not myopically so.  A product is expected to meet a set of financial objectives which justify investing in the product in the first place.  The specific questions being asked do vary from company to company.  They could be items like

  • What percentage of revenue is coming from sales of new products to existing customers, versus existing (subscription, maintenance, etc) product revenue?
  • What is the compound annual growth rate (CAGR) of our free cash flow?
  • What is our churn (or retention) rate for customers in the current year cohort versus last year’s cohort?
Technology Environment

This is a great lens for the champion of the technology team to stand up and say “we need to improve our capability to deliver capabilities” and have it make sense.

You can build a business on a house of cards, or shifting sand, or baling twine – or any other metaphor you desire for “it will all fall apart at some point.”  It would be nice to know when it will fall apart.  It would be even better to change this state (and know it), or prevent it from happening at all.  Interesting questions tend to be a function of “what specifically has been hurting us recently?”

  • What percentage of our investments in quality (e.g. cost of quality) are reactive, versus proactive?
  • How many versions of the product are we simultaneously supporting in the field?
  • What is the 90% time* for customers getting fixes to sev-1 and sev-2 bugs deployed in their environments?

*90% time is the time by which 90% of all fixes have been deployed.  The average time is not nearly as reflective of how well you are serving your customers.  Also note that the measurement is from “reported by customer” to “resolved for customer” and not “validated by QA” to “promoted to trunk by dev.”

Operational Performance

In enterprise software, it isn’t enough to build software, you have to deploy it.  That might take months.  You might be building a business on which the ability to scale is a key assumption of the business case.

The outside-in notion of understanding how your customer defines success (at solving the problem for which they would be using your product) has a nice home here.

You can ask questions like

  • How many man-weeks of effort and calendar-weeks of time are required to deploy the product? [This is another great place for the 90% time]
  • How much faster must our customer’s invoice-processing process be, for them to consider themselves successful?
Conclusion

Each lens provides a perspective on aspects of the product strategy, always relevant to everyone – and often particularly relevant to someone specific.  Combined, the lenses provide the context in which a product manager makes their investment decisions.

The team relies on the product manager to “give them a backlog” and assumes the backlog is identifying the right things to be building.  The definition of right things is a function of product strategy.

How do you know if you have the right product strategy?  The answers are visible through these five lenses.  Now do you believe what they can show you?

Categories: Blogs

Stressfreier arbeiten: 15 Minuten Konzentration

Scrum 4 You - Thu, 04/30/2015 - 07:46

Mein gesamtes Team und ich – also Consultants und unsere unverzichtbaren Stützen aus dem Backbone – haben uns in den letzten Wochen intensiver mit der Theory of Constraints beschäftigt. Die daraus entstandenen Diskussionen darüber, wie wir das auf unsere eigene Arbeit anwenden können, haben mich dazu inspiriert, aus meinem Nähkästchen zu plaudern und mit den anderen einige Techniken zu teilen, die ich für mein Zeitmanagement verwende. Vielleicht ist in den kommenden Folgen auch für Sie etwas dabei, das Sie ausprobieren wollen!

15 Minuten Konzentration, um unliebsame Dinge abzuarbeiten

Wer kennt sie nicht, die ewig lange Aufgabenliste. Meine ist so lang, dass ich oft gar keine Lust mehr habe, sie abzuarbeiten. Die Dinge, auf die ich keine Lust habe, bleiben dann oft auch mal (zu lange) liegen.

Heute mein Tipp, wie ihr mit dieser Aufgabenliste umgehen könntet: Timeboxing.

Schritt1: Jede Aufgabe auf eurer Liste bekommt 15 Minuten eurer Zeit. Ihr stellt euch die Stoppuhr (eine Eieruhr ist genau das Richtige) und dann arbeitet ihr genau 15 Minuten (oder eben so viel Zeit, wie ihr darauf verwenden wollt) an dieser Aufgabe.
Schritt 2: Dann wechselt ihr zum nächsten Task. Wieder 15 Minuten usw., bis jede Aufgabe einmal dran war.
Schritt 3: Daran denken, nach 30 Minuten immer eine Pause von 5 Minuten einzulegen – da schaut man aus dem Fenster oder geht einen Kaffee holen.

Für Fortgeschrittene (Mini-Scrum für mich) 

Wer weiß, dass er jetzt z.B. 2 Stunden am Schreibtisch in Ruhe arbeiten kann:

  1. Handy auf Flugmodus
  2. E-Mail-Programm aus (es sei denn, ihr braucht es zum Arbeiten)
  3. Die Liste der Reihe nach sortieren: Das Schwerste und/oder Ätzendste zuerst (nicht das Wichtigste!).
  4. Dann teilt man die verfügbare Zeit (2 h) durch die Anzahl der in der Liste befindlichen Aufgaben z.B. 10. Also 120 Min. – (4 x 5 Min. Pause) / 10 = 10 Minuten. Jetzt wisst ihr, wie viel Zeit ihr jeder Aufgabe widmen könnt.
  5. Jetzt beginnt ihr, die erste Aufgabe konzentriert für 10 Minuten zu bearbeiten. Wenn sie fertig ist, super, kurz innerlich feiern und zur nächsten Aufgabe übergehen. Wenn man schneller ist: Der entstandene Puffer wird gesammelt. Er wird nicht für eine der nächsten Aufgaben genutzt.
  6. Achtung! Überziehen der Timebox ist bis maximal 10% gestattet. Und es geht sofort mit der nächsten Task weiter (wieder maximal 10 Min.).
  7. Wenn ihr die 10 Aufgaben abgeschlossen habt und noch Zeit übrig bleibt (was euch passieren wird), dann wird gefeiert = nicht noch eine weitere Aufgabe hinzugetan, sondern man geht spazieren oder hört ein wenig Musik. (Grund: sich belohnen und nicht für mehr Leistung auch noch mit mehr Arbeit bestrafen).
  8. Erst nach der Gesamtzeit – also nach den 2 Stunden – den Flugmodus wieder deaktivieren.

Viel Spaß mit diesem Tipp. Mir hilft er immer dann sehr, wenn ich wirklich im Stress bin.

Pixabay CC0 Public Domain

Pixabay CC0 Public Domain

Categories: Blogs

Good Agile Metrics or Working Software

Leading Agile - Mike Cottmeyer - Wed, 04/29/2015 - 21:43

As agile coaches, we use and value metrics as an objective way to evaluate the strengths and weaknesses of teams that we are coaching. When we first engage with a new team, we conduct an agile assessment of the team’s capabilities that results in a baseline metric that pinpoints exactly where we should focus our transformation plan.

The assessment considers team skills in areas like defining the product backlog, planning and coordination, and ability to deliver product. As we progress through our coaching plan, we will conduct additional assessments on a schedule to gauge progress against the baseline, and use the data to tweak our plan of action.

We also use metrics to report fundamental agile stuff to our client’s management team via weekly status reports. These metrics demonstrate team capabilities around things like stable velocity, a team’s ability to finish the sprint and deliver what they said they were going to deliver, and whether teams are stable and members are consistently available to focus on sprint work.

So we view metrics as an important and meaningful tool.

But occasionally we will see situations where the metrics actually become the defining measure of progress and the definition of team success. ScrumMasters worry that if their metrics are not good then “heads will roll” and trouble will ensue. Stand-up meetings become all about discussing what the team needs to do to guarantee favorable agile metrics instead of being about finishing tasks, completing stories and meeting commitments. The team is admonished to log more hours against their open tasks if the sprint burn-down deviates slightly above the ideal line.

Don’t lose sight of the real measure of success, which is producing working and tested software consistently at the end of every sprint. Metrics can help guide you to stay the course for your agile journey, but should never become the primary measure of whether a team is really agile or not.

The post Good Agile Metrics or Working Software appeared first on LeadingAgile.

Categories: Blogs

Opening the Door to a Future in Tech

Rally Agile Blog - Wed, 04/29/2015 - 15:00

“If a low-income student becomes engaged in programming, it’s like winning a lottery ticket! She would not otherwise even know that this field existed. They don’t have these examples within their communities.” — Becky Kivlovitz, “I Have A Dream” Foundation of Boulder County

Seventeen middle school Dreamers recently spent a day off from school experiencing firsthand what it’s like to be a software engineer. Volunteers from Rally's engineer team at our Boulder, Colorado, headquarters paired with students for an interactive day of exploration and hands-on learning.

"I Have a Dream" is a long-term, year-round program that works with the same group of children from their elementary school years through college. One-hundred percent of the Dreamers are low income: they either live in low-income public housing projects or are eligible for the federal free- and reduced-lunch program at their schools.

“It’s awesome to see our students getting one-on-one attention and hands-on learning — this doesn’t normally happen in their classrooms. I see technology as our future and I worry that kids who are in low-income communities might not be able to keep up with this change due to a lack of resources and inequity. For them to experience a technology career here at Rally is extremely exciting and I feel will really impact them and make a difference in their future.” — Rachael Durham, Americorp volunteer with “I Have A Dream” Foundation of Boulder County

Rallyers designed the day using their own experience, knowledge, and skills — and were challenged to make software engineering interesting and fun for kids aged 11–13. They started off learning about hardware, looking inside computers and servers, and touring Rally’s data center. Then the kids paired with their Rally partners to create a website and simple game.

“This is exactly what I want to do with my 1% volunteer time off.” — Beth Medina, Rally Infrastructure Engineer

“The tour was enlightening to them. I don’t think they ever thought there could be such a cool place to work!” — Melissa Gallegos, Rally Customer Success Operations Manager

“We’re always looking for ways to motivate a kid to do their homework. If we can show them an interesting career path, we can remind them that there is a reason they need to study and learn.” — Becky Kivlovitz, “I Have A Dream” Foundation of Boulder County

Geri Mitchell-Brown
Categories: Companies

Opening the Door to a Future in Tech

Rally Agile Blog - Wed, 04/29/2015 - 15:00

“If a low-income student becomes engaged in programming, it’s like winning a lottery ticket! She would not otherwise even know that this field existed. They don’t have these examples within their communities.” — Becky Kivlovitz, “I Have A Dream” Foundation of Boulder County

Seventeen middle school Dreamers recently spent a day off from school experiencing firsthand what it’s like to be a software engineer. Volunteers from Rally's engineer team at our Boulder, Colorado, headquarters paired with students for an interactive day of exploration and hands-on learning.

"I Have a Dream" is a long-term, year-round program that works with the same group of children from their elementary school years through college. One-hundred percent of the Dreamers are low income: they either live in low-income public housing projects or are eligible for the federal free- and reduced-lunch program at their schools.

“It’s awesome to see our students getting one-on-one attention and hands-on learning — this doesn’t normally happen in their classrooms. I see technology as our future and I worry that kids who are in low-income communities might not be able to keep up with this change due to a lack of resources and inequity. For them to experience a technology career here at Rally is extremely exciting and I feel will really impact them and make a difference in their future.” — Rachael Durham, Americorp volunteer with “I Have A Dream” Foundation of Boulder County

Rallyers designed the day using their own experience, knowledge, and skills — and were challenged to make software engineering interesting and fun for kids aged 11–13. They started off learning about hardware, looking inside computers and servers, and touring Rally’s data center. Then the kids paired with their Rally partners to create a website and simple game.

“This is exactly what I want to do with my 1% volunteer time off.” — Beth Medina, Rally Infrastructure Engineer

“The tour was enlightening to them. I don’t think they ever thought there could be such a cool place to work!” — Melissa Gallegos, Rally Customer Success Operations Manager

“We’re always looking for ways to motivate a kid to do their homework. If we can show them an interesting career path, we can remind them that there is a reason they need to study and learn.” — Becky Kivlovitz, “I Have A Dream” Foundation of Boulder County

Geri Mitchell-Brown
Categories: Companies

Experimenting With External Blog Pressure

Over the past several years my blog has followed the path of many others gradually following into an irregular posting schedule until there were no more than a few posts per year. I always felt guilty, but not enough to really put true effort into restarting it. I came across a pots on SimpleProgrammer.com offering a short email driven program to startup/restart a blog and I went ahead and signed up. Sometimes a bit of external pressure is just enough to restart a habit. So this is the third new post in the last 2 weeks, and I’m attempting to post every Monday now. Can’t complain that it hasn’t worked so far and feel free to blast me if I start falling short.

Categories: Blogs

Announcing SonarQube integration with MSBuild and Team Build

Sonar - Wed, 04/29/2015 - 00:20

This is a cross-post of Microsoft ALM web site.

Technical debt is the set of problems in a development effort that make forward progress on customer value inefficient. Technical debt saps productivity by making code hard to understand, fragile, difficult to validate, and creates unplanned work that blocks progress. Technical debt is insidious. It starts small and grows over time through rushed changes, lack of context and lack of discipline. Organizations often find that more than 50% of their capacity is sapped by technical debt.

SonarQube is an open source platform that is the de facto solution for understanding and managing technical debt.

Customers have been telling us and SonarSource, the company behind SonarQube, that the SonarQube analysis of .Net apps and integration with Microsoft build technologies needs to be considerably improved.

Over the past few months we have been collaborating with our friends from SonarSource and are pleased to make available a set of integration components that allow you to configure a Team Foundation Server (TFS) Build to connect to a SonarQube server and send the following data, which is gathered during a build under the governance of quality profiles and gates defined on the SonarQube server.

  • results of .Net and JavaScript code analysis
  • code clone analysis
  • code coverage data from tests
  • metrics for .Net and JavaScript

We have initially targeted TFS 2013 and above, so customers can try out these bits immediately with code and build definitions that they already have. We have tried using the above bits with builds in Visual Studio Online (VSO), using an on-premises build agent, but we have uncovered a bug around the discovery of code coverage data which we are working on resolving. When this is fixed we’ll send out an update on this blog. We are also working on integration with the next generation of build in VSO and TFS.

In addition, SonarSource have produced a set of .Net rules, written using the new Roslyn-based code analysis framework, and published them in two forms: a nuget package and a VSIX. With this set of rules, the analysis that is done as part of build can also be done live inside Visual Studio 2015, exploiting the new Visual Studio 2015 code analysis experience

The source code for the above has been made available at https://github.com/SonarSource, specifically:

We are also grateful to our ever-supportive ALM Rangers who have, in parallel, written a SonarQube Installation Guide, which explains how to set up a production ready SonarQube installation to be used in conjunction with Team Foundation Server 2013 to analyse .Net apps. This includes reference to the new integration components mentioned above.

This is only the start of our collaboration. We have lots of exciting ideas on our backlog, so watch this space.

As always, we’d appreciate your feedback on how you find the experience and ideas about how it could be improved to help you and your teams deliver higher quality and easier to maintain software more efficiently.

Categories: Open Source

Book Review: Software Architecture for Developers

thekua.com@work - Tue, 04/28/2015 - 22:48

Simon Brown’s book, Software Architecture for Developers has been on my reading list for some time. I am aware of Brown’s talks that he gives at conferences, and his very good workshop on describing how to draw more effective diagrams as a communication mechanism for developers to other groups, but I wasn’t quite sure what his book was going to cover.

Software Architecture for Developers

This weekend, whilst travelling, I had a bit of airport time to do some reading to plough through his book.

What I enjoyed about the book
Architecture is a touchy subject, and Brown doesn’t have any problems raising this as a contentious topic, particularly in the agile community where it doesn’t have an explicit practice. Some XP books explain the role, but mantras like “Big Design Up Front” and “Last Responsible Moment” are often (wrongly) interpreted as “do no architecture.” What I liked about Brown’s approach is his recognition of the Goldilocks approach – not too little and not too much where he provides both points of view and some concrete practices.

Brown covers important topics like quality attributes (Cross Functional Requirements), what the role of an Architect is (and that it is just a role, not necessarily a person). I am biased in the opinion but I enjoyed Brown’s perspective about whether or not architects should code, and it aligns well with my own point of view that for a Tech Lead (or Architect) to make effective decisions, they need to have empathy and understand (live, breath and sometime burn for) the decisions they make.

I appreciated the way that Brown puts “Constraints” and “Principles” as key factors that aren’t necessarily represented in the codebase and are unlikely to be easily discoverable for new people. Both are things that I have done when leading software teams and are things I would repeat because I find it helps people navigate and contribute to the codebase.

What I found slightly strange about the book

I believe the book is really strong but there were a few sections that seemed slightly out of place, or not yet completely finished. One was around the “Sharepoint projects needs architecture too”, which I don’t necessarily disagree with but could easily be extended to “Any software product extended to build an application needs architecture too” (cue s/Sharepoint/CMS/g or other examples).

Conclusion

Software Architecture for Developers is a very accessible, relevant and useful book that I do not have any problems recommending for people looking at how to effectively implement Software Architecture in today’s environment.

Categories: Blogs

VersionOne Spring Release Includes Performance Scorecards

Scrum Expert - Tue, 04/28/2015 - 18:16
VersionOne has announced its 2015 Spring Release. The release includes new features such as Performance Scorecards to visually track software development progress and Communities to promote agile best practices across organizations. These latest platform innovations will help organizations make more informed decisions, improve planning, and drive agile consistency. The new VersionOne capabilities improve business alignment and agility to adapt to evolving plans and priorities: * Performance Scorecards: Get instant access to a barometer of your key performance indicators at each organizational level: portfolio, program, and team. * Communities: Build, maintain and promote agile ...
Categories: Communities

Scrum Day San Diego, San Diego, USA, June 12 2015

Scrum Expert - Tue, 04/28/2015 - 17:25
The Scrum Day San Diego is a one-day conference that offers the very best platform to share real world ideas, practices and techniques on Scrum, Lean and all things Agile in San Diego County. This single-track conference will be your opportunity to hear how other people from San Diego County navigated these murky steps as they share their stories. Learn from people who have been there and done that. In the agenda of the Scrum Day San Diego you can find topics like “A Bad Start:  Why Agile Teams Ignore 75% ...
Categories: Communities

A3 problem solving template – now in Google Doc!

Henrik Kniberg's blog - Tue, 04/28/2015 - 16:49

I’ve finally gotten around to porting the A3 template to Google Doc. Who wants to send around MS Word docs and PDFs? Bah. Put the doc in the cloud instead, where everyone can see and edit together. Or print the template and do it by hand.

Curious about A3 problem solving? See the FAQ.

Here’s a direct link to the template.

A3 template

Enjoy!

Categories: Blogs

Can a ScrumMaster Work with More than One Team?

Scrum Expert - Tue, 04/28/2015 - 15:58
The ScrumMaster is a key element of the Scrum teams that need such a role for facilitating their work. In his book “Scrum Shortcuts without Cutting Corners”, Ilan Goldstein discusses the question if a ScrumMaster can be member of more than one Scrum team. Many in the Scrum community will strongly argue that the ScrumMaster role is significant enough to justify a “one team = one ScrumMaster” configuration. I support this argument, and Shortcut 26 highlights plenty of conclusive reasons demonstrating why being a ScrumMaster is absolutely a full-time role. That ...
Categories: Communities

XP2015, Helsinki, Finland, May 25-29 2015

Scrum Expert - Tue, 04/28/2015 - 14:02
XP2015 is a four-day conference on extreme programming and Agile software development that takes place in Helsinki, Finland. This is the event where Agile and Lean practitioners and researchers should meet. In the agenda of the XP2015 conference you can find topics like “Continuous Delivery with Docker and Jenkins Job Builder”, “Collaborative Exploratory and Unit Testing”, “Fearless Change: Patterns for Introducing New Ideas”, “Agile methods applied to development and certification of safety-critical software (ASCS)”, “Keynote: New Directions for Software Development Process”, “Fun Retrospectives: Activities and ideas for making agile retrospectives more ...
Categories: Communities

does it hurt when you stop?

Derick Bailey - new ThoughtStream - Tue, 04/28/2015 - 12:00

Hold your cell phone up to your face, like you’re talking to someone… keep it there for 20 or 30 minutes, constantly holding your arm tight as you do. When you finally decide to put the phone down, your arm is going to be tired and sore. It’s going to hurt just to put the phone down.

The same thing is happening with my eyes and my new glasses. I’ve had these glasses for about 2 weeks now, and it hurts my eyes to use them. But I keep wearing my new glasses, forcing myself to adjust to them. I do this for the same reason that I put down the phone after an extended conversation; in spite of how much it hurts my arm to put it down, it is better to deal with that pain now than the constant and enduring pain of always holding my arm tightly closed.

Living With Pain

There are some schools of thought that say pain never really goes away. Instead, we learn to live with it. The pain that we experience becomes the new normal, a baseline of where we are at any given time.

I think this is true in some cases – like the way I used to focus my eyes, prior to having these new glasses.

I don’t think this school of thought is true in all cases, though. Putting down the phone allows my arm to relax and heal itself, for example. Once my arm has rebuilt it’s supply of energy and released all the things that had built up while hold the phone, the pain does go away.

Crash

Sometimes we don’t realize we’re living with pain, because it has become the new normal. It’s surprising how quickly things become “normal”, as well.

If the pain we feel is slowly onset, it can be like boiling a frog. We don’t realize we’re being cooked until it’s too late. There may be a sharp end or a crash coming up, but we don’t know it because we don’t recognize the pain.

I go through cycles on a fairly regular basis, with various points of stress in my life. When I work extra hours toward a project deadline, for example, I carry a heavy burden of stress. It is physically and mentally taxing. I quickly become accustomed to it, though and it becomes my new normal. I forget that the pain, the stress and the issues that result from these, are there.

At the project end, once the deadline is passed, or when the situation finally resolves itself, I crash. Hard. My body shuts down. My brain won’t think. I often get sick with flu-like symptoms, general fatigue and aches, and have to spend a week or more in recovery mode.

Recovery

When I’m in recovery mode, I’ll stay home from work. I’ll watch movies and take naps during the day. I’ll eat extra food and let my work go unattended. I won’t answer emails often enough. I won’t attend meetings. I’ll call in sick, essentially. Because if I don’t, I put myself at even greater risk of an even larger and more dangerous crash.

Much like the time that someone spends in a hospital, after surgery or other medical procedures, the time I spend in recovery is important. It is time that my body, my mind, my motivation and my desire to continue working, needs.

What Doesn’t Kill You, Only … ???

This isn’t good for me. Not by any means. These cycles of stress – mentally, physically and otherwise – take a toll on me. Every cycle I go through leaves me with less than I had before. Less time, less motivation, less ability to care and do my job.

I used to tell myself that it was making me stronger. Maybe it was when I was a kid – late teens, early twenties. But the reality of what this is doing to me is sinking in, slowly but surely, year after year. And it’s not good.

No one should have to go through cycles of pain like this; building up, crashing, recovering and starting over again. It is a terrible way to live.

Feeling Pain

If I hold the phone to my face for too long, my arm hurts. I know the stress I am putting my arm through. When I am finally done holding the phone, my arm hurts more. It has to recover. This is pain that should be prevented. I should switch hands to hold the phone, use a hands-free head set or find another alternative.

I’ve spent the last however-many years straining my eyes to see. My eyes became accustomed to the stress, the pain and the difficulty of focusing. Now that I have my glasses, I have to accept this pain of allowing my eyes to relax. It’s like I’ve held my phone in my arm for 20 or 30 years, and now I have to put it down. But I know that if I allow my eyes to recover through the use of these glasses, that my eyes will experience less strain and pain over-all.

Recognize The Difference

Learning to live with pain is something that we have to deal with far too often. The death of a loved one, a friend moving away, relationships that end – there are some pains that will never go away, or take a tremendously long time to go away.

But that doesn’t mean we should learn to always live with every pain. There are some pains that can and should go away. We need to learn to recognize the difference in the pains we are feeling.

– Derick

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.