Retaining and Growing Readers on Newspaper Web and Mobile Sites

I am from one of the last generations of ritual NY Times Sunday edition readers. I have fond memories of taking the tree with me to parks and beaches during the summertime to read the magazine and many of the other sections. I even found my first out of college jobs from a help wanted ad in the Times that my wife (then girlfriend) mailed to me while finishing grad school at the University of Arizona.

Flash many years later, and how do I read the Times?

Several years ago I became a web only reader but never signed up for Times Select despite missing my weekly dose of Thomas Friedman. When I got a blackberry, I became largely a mobile user and read most of the articles I wanted during my commute. Sometimes, I feel like I'm missing something when reading the mobile dining section while catching a glimpse of the full color print edition that the person next to me is browsing, but it still doesn't compel me to buy a copy.

And now of course there's my Twitter stream. I get most of the NYT articles that I would want to read from the NYT Business Twitter feed plus tweets from friends. So I don't visit the NYT mobile every day now. Now, even when the NYT finds a way to monetize mobile, my engagement will be limited to the articles I read with little opportunity to present related content or social experiences that would drive higher engagement.

Such is the difficulty of the traditional and newspaper publisher who is trying to retain subscriptions, increase digital readers, and increase engagement. It's a hard problem. News sites have to get very strong at working web analytics, understanding how to reach new audiences, and essentially targeting some of their writing based on audience needs. I will continue to read the NYT, they will just have to work harder to get my attention.
continue reading "Retaining and Growing Readers on Newspaper Web and Mobile Sites"

Business Responsibilities working with Agile Teams Part 2

See Business Responsibilities working with Agile Teams Part 1 where I cover some important responsibilities: Dedicating time to define requirements, setting reasonable customer expectations, and developing a methodology for prioritizing.

The list below is a bit more tactical and technical:

1) Learn the lingo and the process - Don't look at agile as a 'tech process'. When I discuss agile to business executives, I explain that when tech teams are successful adopting agile, it creates significant organizational change at the business level. One good way to insure a smooth transition is to learn the process either through participation, taking a training class, and ideally applying agile/SCRUM as a business process. This white paper, Agile Terminology Explained is a good quick read.

2) Avoid the need to add/change stories inside the iteration - which can be very disruptive to the team. Agile teams work in rhythms. At the beginning of the iteration, they are in thinking/planning mode. During the iteration, they are focused on stories and coding and at the end of the iteration they are closing out defects. Changes midstream create an imbalance. Now most teams are flexible (being agile) and will accept changes/additions, but this should be managed as an exception, not the norm.

3) Come to demos - Demos are when the team showcases the work of the iteration. The team goes through story by story and demonstrates the functionality. If business representatives or stakeholders do not attend regularly, they miss the opportunity to provide valuable feedback on the finished product. It also demoralizes the team. It doesn't mean that you have to attend every demo - I certainly have missed my share (sorry guys) - but attendance is key to a successful agile practice.

4) Help define acceptance criteria - Agile stories are most successful when the story is a deliverable or unit of result. The team will come up with technical criteria for acceptance, but these criteria have more meaning when they qualify a real business need.

5) Prioritize tech needs too! - Successful agile practices need to appropriate time to implement tech concerns. R&D efforts, managing support issues, addressing technical debt (when messy code needs to be fixed), documentation concerns, training...

More on agile? Great articles posted at the Business Exchange Agile Software Development topic.
continue reading "Business Responsibilities working with Agile Teams Part 2"

Business Responsibilities working with Agile Teams Part 1

I enjoy talking to General Managers, Product Managers, and other members of a business teams about the benefits of going agile. Their eyes light up when I talk about the basics. They get to see completed product at the end of each iteration, get the ability to change priorities and requirements, and there is minimal up front work developing requirements. They 'get it' - speed to market and the ability to adjust to market demands.

But I warn business managers that with agile comes some new responsibilities. Below is an incomplete list of some things the Business needs to manage when working with an Agile software development team

1) Expect to spend a lot of time with the technologists! - The agile practice requires a strong commitment from business managers to help set priorities and communicate requirements. In our practice for development on Business Exchange, the technologists meet with the senior business managers no less than three hours per week for iterations that are three weeks in length. This is followed up by many small meetings to help capture requirements with individual stakeholders. It is time consuming and intense.

2) Set reasonable expectations with customers on the scope of product delivery. Agile teams should be good at hitting time lines and budgets, but because priorities and requirements are adjusted each iteration, it's hard to know the exact functionality that will be available in a future release. That's one reason creating a vision statement is key. It not only focuses the team on the key deliverable, it also is a tool to help market the product. But when a customer asks about whether a specific feature will be in a release, be prepared to capture the data point (aha, one reason to prioritize this feature) and respond accordingly.

3) Develop a methodology for prioritizing. Agile forces you to prioritize frequently and this can be a hard exercise for business managers if they don't have prioritization streamed into a repeatable process. Most organizations have multiple stakeholders, so having a transparent methodology makes it easier to keep everyone informed and understanding why Story X is #1 going into Commitment. Still, prioritizing is really hard especially when you get used to frequent releases. Say the team's iteration is a month and usually handles ten stories each iteration. The eleventh story, the one the team probably doesn't commit to, will have to wait two iterations (two months) for its completion. Very quickly, Business Managers feel the difficulty in picking the right ten stories/priorities for the coming iteration.

Three more in the next post!
continue reading "Business Responsibilities working with Agile Teams Part 1"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.